Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/Appwrite/SDK/Specification/Format/OpenAPI3.php`:
- Around line 845-847: The OpenAPI3.php switch handling the 'id' type sets $type
= 'integer' but leaves $format null, causing sequence schemas to lack a format;
update the 'id' case (in the same switch where $type and $format are set) to
also assign $format = $rule['format'] ?? 'int32' (mirroring the fix in
Swagger2.php) so that the integer schema for $sequence includes the proper
format.

In `@src/Appwrite/SDK/Specification/Format/Swagger2.php`:
- Around line 825-827: Update the 'id' switch case in Swagger2.php to explicitly
set $format (same pattern as the 'integer' case) so ID fields emit a format;
specifically assign $format = $rule['format'] ?? 'int32' (or 'int64' if your IDs
can exceed 2,147,483,647) next to where $type = 'integer' is set, ensuring the
variables $type, $format and $rule are used consistently when serializing the
schema.

---

Outside diff comments:
In `@src/Appwrite/Utopia/Response/Model/Document.php`:
- Around line 39-45: The $sequence rule in the Document model uses TYPE_ID (an
integer type) but sets 'default' => '' and 'example' => '1', causing a
string-vs-integer mismatch; update the addRule entry for '$sequence' in the
Document class to use integer values ('default' => 0 and 'example' => 1) so they
match TYPE_ID and the runtime cast logic that handles sequence IDs.

In `@src/Appwrite/Utopia/Response/Model/Row.php`:
- Around line 39-45: The default and example for the '$sequence' rule are
strings but the field is integer-typed (TYPE_ID) and cast to int in the filter()
method; update the addRule entry for '$sequence' to use integer values (e.g.,
'default' => 0 and 'example' => 1) so OpenAPI/Swagger generators see numeric
types and examples consistent with TYPE_ID and the filter() behavior, leaving
'readOnly' and other keys unchanged.

---

Duplicate comments:
In `@src/Appwrite/SDK/Specification/Format/OpenAPI3.php`:
- Around line 845-847: The switch branch mapping TYPE_ID (the case 'id' in
OpenAPI3.php) currently returns 'integer', which duplicates the breaking
contract change flagged in Swagger2; change the mapping back to the non-breaking
type (e.g., 'string' or the previously used representation for TYPE_ID) so
component schemas keep the original contract. Update the case 'id' branch in the
OpenAPI3 specification generator (where TYPE_ID is handled) to emit the original
type/format used before the breaking change and ensure any related schema
generation logic references the same representation.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/Appwrite/SDK/Specification/Format/OpenAPI3.php`:
- Around line 845-848: The OpenAPI3 specification generator currently sets IDs
to integer with a default format of 'int32' in the case 'id' branch; update that
fallback (in the switch handling for 'id' inside
src/Appwrite/SDK/Specification/Format/OpenAPI3.php) to use 'int64' instead of
'int32' so sequence/auto-increment IDs are represented as 64-bit integers (i.e.,
change the $rule['format'] ?? 'int32' fallback to $rule['format'] ?? 'int64').

In `@src/Appwrite/Utopia/Response/Model/Document.php`:
- Around line 86-87: The code is setting a default $sequence=0 via
getAttribute('$sequence', 0) which then gets materialized for documents that
never had the field; change the check to only act when the attribute actually
exists (e.g. use $document->hasAttribute('$sequence') or call
getAttribute('$sequence') without a default and check !== null), then if the
attribute exists and is numeric cast and call
$document->setAttribute('$sequence', (int)...). Update the block around the
Document handling (the $document variable / methods getAttribute, hasAttribute,
setAttribute) to avoid using the default 0 when determining whether to set the
attribute.