feat: API specs update for version 1.9.x

[appwrite-specs]

This PR contains API specification updates for version 1.9.x.

[greptile-apps]

Greptile Summary

Adds a type discriminator field to providerRepositoryFrameworkList and providerRepositoryRuntimeList schemas in both the OpenAPI 3 and Swagger 2 specs, enabling client tooling to resolve the oneOf union in the provider repository list response. The Swagger 2 spec correctly uses x-discriminator (vendor extension) since OpenAPI-3-style mapping objects are not part of the Swagger 2 standard.

Confidence Score: 5/5

Safe to merge — changes are additive, structurally correct, and only affect schema metadata used by code generators and validators.

Both files receive identical, symmetric changes. The OpenAPI 3 discriminator usage follows the spec correctly (discriminator at the oneOf level with all referenced schemas carrying the property). The only finding is a P2 suggestion to add enum constraints to the type field; this doesn't affect correctness or runtime behavior.

No files require special attention.

Important Files Changed

Filename	Overview
specs/1.9.x/open-api3-1.9.x-console.json	Adds discriminator object to the oneOf response schema for provider repository lists, and adds a required type field to both providerRepositoryFrameworkList and providerRepositoryRuntimeList schemas to support discriminated union resolution.
specs/1.9.x/swagger2-1.9.x-console.json	Mirrors the OpenAPI 3 changes — adds x-discriminator extension and a required type field to both list schemas. Uses x-discriminator (vendor extension) instead of Swagger 2's native discriminator string, since OpenAPI-3-style mapping objects are not natively supported in Swagger 2.

_{Reviews (1): Last reviewed commit: "chore: update API specs and SDK examples" | Re-trigger Greptile}

[greptile-apps]

type field missing enum constraint

The type discriminator field is defined as a plain string in both providerRepositoryFrameworkList and providerRepositoryRuntimeList, but the only valid values are "framework" and "runtime". Without an enum constraint, validators and code generators will accept any string, reducing the precision of the schema.

Suggested change

	},
	"type": {
	"type": "string",
	"description": "Provider repository list type.",
	"x-example": "framework"
	"type": {
	"type": "string",
	"description": "Provider repository list type.",
	"enum": ["framework"],
	"x-example": "framework"
	}

The same applies to providerRepositoryRuntimeList's type field ("enum": ["runtime"]).