supabase link fails on v2.112.0: SchemaError on api-keys inserted_at (regex requires Z suffix)

[messy-michael]

Describe the bug

Since v2.112.0, supabase link fails for every project with a schema
validation error while fetching API keys:

failed to get api keys: SchemaError(Expected a string matching the RegExp ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z))$
  at [2]["inserted_at"])

v2.111.0 works against the same project with the same credentials.

The decoded value comes from GET /v1/projects/{ref}/api-keys. The regex in
the generated V1GetProjectApiKeysOutput schema (@supabase/api/effect)
accepts a Z suffix only, but the Management API returns an inserted_at
value for at least one key (index [2], i.e. not the first two rows) that the
pattern rejects. So the CLI's own generated schema is stricter than the API it
is decoding.

Because link caches API keys, this makes the command — and therefore any CI
pipeline built on link + db push — fail outright. There is no flag to skip
the key fetch.

Secondary issue: it is reported as a network error

In apps/cli/src/legacy/shared/legacy-get-api-keys.ts, mapApiKeysError is
built with mapLegacyHttpError({ networkMessage: (cause) => failed to get api
keys: ${cause} }), and the schema decode failure is funnelled through that
networkMessage path. A client-side validation bug therefore surfaces with
wording that implies a transport or credentials problem.

This cost real debugging time — the failure looks like an auth/network/infra
issue, so the first hours went into access tokens and CI configuration rather
than the CLI. Decode errors would ideally be mapped to their own error with a
message naming the field and the received value.

To Reproduce

1. Have a project with at least three API keys.
2. Install CLI v2.112.0.
3. supabase link --project-ref <ref>
4. Observe the SchemaError above.

supabase projects api-keys --project-ref <ref> fails the same way, since it
shares legacyGetProjectApiKeys.

Expected behavior

link succeeds, as it does on v2.111.0. The generated schema should accept
every timestamp format the Management API actually emits for inserted_at /
updated_at (timezone offsets and varying fractional-second precision, not
just Z).

System information

• Version of the CLI: 2.112.0 (regression from 2.111.0)
• Environment: GitHub Actions ubuntu-latest, installed via
  supabase/setup-cli with version: latest; also reproduces outside CI.

Workaround

Pinning supabase/setup-cli to version: 2.111.0.