flowctl: fetch storage mappings and data planes via GraphQL

[GregorShear]

Summary

Resolves storage mappings and accessible data planes during flowctl source loading through the control-plane GraphQL API instead of PostgREST.

Why

The PostgREST path relied on row-level security, whose grant graph only walks downward: a user scoped to a sub-prefix (for example, acmeCo/team-a/) could not read the tenant-root mapping at acmeCo/, so flowctl discover failed with an access error. The GraphQL resolvers authorize against the snapshot grant graph, which walks ancestors as well as descendants.

A storage mapping identifies eligible data planes by name, while existing live specs reference their assigned data plane by ID. The dataPlanes GraphQL query now returns both values, allowing local validation to resolve either form without depending on legacy RLS.

How

• Storage mapping prefixes are fetched with filter: { catalogPrefix: { in: [...] } } exact-set queries, batched at the filter's 100-entry limit.
• All accessible data planes are fetched through the paginated dataPlanes connection. This is necessary because storage mappings reference planes by name rather than ID.
• Unreadable resources are filtered by the server. Transport, HTTP, and GraphQL execution errors propagate.
• Recovery mappings continue to be synthesized client-side with a zero control ID.

The storage mapping filter landed in #3242. Data-plane IDs landed in #3240. Live specs and inferred schemas remain on their existing PostgREST paths.

Testing

• cargo test -p flowctl — 25 passed.
• cargo fmt --all -- --check — clean.
• The production discover smoke test currently stops with Unknown field "id" on type "DataPlane", confirming production has not yet deployed the schema from control-plane-api: add id and an id filter to the dataPlanes GraphQL query #3240. Rerun the smoke test after that control-plane API deployment.