docs(specs): add S25 IAM relationships client spec

What

Adds S25 — IAM relationships client (docs/specs/S25-iam-relationships-client.md) and indexes it in the spec catalog. The spec defines the Artifact Registry client to the IAM data layer's Lookup service (gitlab.iam.lookup.v1.LookupService/ReadRelationships), which resolves relationship tuples for host-side authorization input assembly per ADR-024 (east-west headless-service topology) and the embedded-GLAZ interim design.

Opened with Status: Draft — per the project guardrails the merge is the approval signal.

Scope

Client transport only:

• dns:/// resolver + round_robin load balancing, keepalive (30s/10s, PermitWithoutStream), bounded retry policy (UNAVAILABLE/DEADLINE_EXCEEDED, exponential backoff) via gRPC service config.
• Two per-RPC credentials: forwarded end-user JWT (authorization: Bearer) + shared Vault service token (gitlab-iam-data-access-token).
• gRPC health checking (grpc.health.v1.Health/Check) and a Health(ctx) probe.
• Per-RPC latency + error metrics following S03-B; LB endpoint distribution via channelz / OTel stats.
• A domain Resolver interface that keeps gRPC and generated-proto types off the caller boundary.

Authorization input assembly and the decision itself are out of scope, deferred to the spec that replaces the S09 stub.

Key decisions (recorded in the spec's Resolutions)

• Proto schema sourcing: interim vendir vendoring + local buf codegen, pending the cross-team proto-discovery decision in iam#55. Mirrors the Rails vendored-client precedent (gitlab!241296).
• LB observability: channelz / OTel stats rather than a churning pod-IP Prometheus label (honors S03-B cardinality governance).
• Credentials: two per RPC. Audience is opaque to AR — the forwarded JWT carries gitlab-artifact-registry, accepted by iam-data-access on the interim path (iam#56) — so no audience configuration is exposed. Two deliberate divergences from issue #205 (moved)'s literal wording (credential carriage and audience) reflect what IAM actually validates.

Next steps

Per the spec → plan → implementation workflow: a plan MR follows once this merges, then implementation MRs (test-author, then implementation-author).

Related to #205 (moved)