Self-service private-link configuration

[jshearer]

This PR exposes the data_planes.private_links configuration through the GraphQL API. Today private data-plane customers file a support request and we edit the column by hand.

dataPlanes query: private-networking fields

• privateLinks returns the configured endpoints as a typed union (AWSPrivateLink | AzurePrivateLink | GCPPrivateServiceConnect).
• awsLinkEndpoints / azureLinkEndpoints / gcpPscEndpoints expose the provisioning results the data-plane controller writes back, as opaque JSON.
• All four fields are gated on the ViewDataPlanePrivateNetworking capability and fail closed to an empty list.

updateDataPlanePrivateLinks mutation

• Takes [PrivateLinkInput!]!, a oneof input mirroring the union, and replaces the entire private_links array on a private data plane; partial updates are intentionally not supported. The DPC converges to the new configuration on its next poll.
• Requires ModifyDataPlanePrivateNetworking on the data-plane name, after a structural check that the name is under ops/dp/private/<tenant>/.

Authorization model

• Two new capability bits: ViewDataPlanePrivateNetworking and ModifyDataPlanePrivateNetworking.
• The Viewer bundle (and therefore legacy read) carries the View bit: read on a data-plane prefix already conveys deploy-level trust, so viewing the plane's networking configuration comes with it.
• Modify reaches a tenant admin through the conjunction of two grants: the ops/dp/private/<tenant>/ role_grant must carry the new ManageDataPlane bundle (create_data_plane installs it at provisioning time; a migration backfills existing private data planes), and the user's own bits at the tenant must include the bit, which today means admin since Admin folds ManageDataPlane in. Bits intersect along the delegation chain, so neither grant alone conveys Modify.
• To grant ModifyDataPlanePrivateNetworking to a non-admin, create a user_grant on the tenant carrying {manage_data_plane, delegate} (Editor already carries Delegate, so editors need only manage_data_plane).

Shared models

• The PrivateLink types moved from data-plane-controller::shared::stack to models, with feature-gated async-graphql derives so one set of structs backs the DB column, the GraphQL schema, and the DPC (which re-exports them).
• Azure's dns_name / resource_type are now Option<String>. The previous shape was String with skip_serializing_if = "String::is_empty", so "" and absent were already indistinguishable on the wire: both serialized as a missing field. The new deserializer normalizes an incoming "" to None, and serialization stays field-absent, so the stored bytes and the stack config est-dry-dock reads are identical for every historical row shape (absent, "", or a value); a round-trip test in models::private_links pins this.
• est-dry-dock cannot observe the difference either: its Pydantic models default these fields to "" and use truthiness checks. The visible effect is confined to GraphQL, where the fields are nullable and rows that stored "" surface as null.

Reviewer notes

Trade-offs discussed during review, recorded so they don't need to be re-litigated:

• The four private-networking resolvers are deliberately not deduplicated further. The non-trivial shared piece, the capability check, is the authorized() helper in graphql/mod.rs; what remains per resolver is the gate call plus a clone-and-wrap body. A gated_endpoints helper bundling the gate and the JSON mapping was tried and dropped as trivial-body indirection under a vague name. Keeping the gate visible inside each resolver keeps the authorization audit local; the cost is that a change to the denial behavior must be edited in four places.
• Azure Option<String> was chosen over two alternatives: keeping String (zero glue, but the "" sentinel becomes part of the public GraphQL contract as String!), and mapping "" to null at the GraphQL layer only (DPC untouched, but it requires an Azure-only split of input and output types while the model keeps the sentinel). Normalizing in models costs a small serde adapter plus a round-trip test, and makes the nullable contract hold everywhere the type is used.
• ViewDataPlanePrivateNetworking is kept as its own bit even though read currently implies it via Viewer. The rejected alternative was to drop the bit and let DP-node visibility be the gate, which would have deleted the field gates entirely. Keeping the bit means each field gate names its capability explicitly, and the View / Modify split survives future changes to what read implies.

Deployment note

Migrations are applied manually; the sequencing matters:

• Apply the enum migration before deploying: the new create_data_plane binds the manage_data_plane value, so provisioning a private data plane on the new code errors if the value is missing. (Two migration files because alter type add value cannot be referenced in the same transaction.)
• Run the backfill only after the rollout completes: binaries built before this PR decode bundles strictly in the snapshot loader, so any row carrying manage_data_plane breaks their role_grants fetch. For the same reason, do not provision a private data plane mid-rollout while old pods are live.
• In the window between deploy and backfill, tenant admins of existing private data planes can view private links but not modify them. The backfill is idempotent and skips rows that already carry the bundle, so it is safe to run any time after the rollout, and planes provisioned on the new code are unaffected by it.

Fixes #2773