docs: federate the read side into api.sr.ht from Phase 2

Reverses the earlier no-federation call. The deciding arguments are one
endpoint plus one meta PAT for agents already querying git/todo/builds,
hut ergonomics, and core-go/webhooks being GraphQL-native so Phase 5
pulls gqlgen in regardless. The dolt precedent does not generalize: its
API is a chunk-store protocol, whereas documents and proposals are an
ordinary CRUD graph.

Mutations stay on REST + MCP. If-Match optimistic concurrency is an HTTP
idiom with well-defined 409 semantics, and a federated type is a consumed
contract, so the unsettled proposal types stay out of the gateway.

Also records that federation is not cross-service search: thistle merges
schemas and routes fields, so the meta-project still needs our own index.

docs: add SourceHut integration section to the spec.sr.ht design

Records the config-driven wiring (Recipe B: pure Go, chrome copied from
compare.sr.ht), the canonical [spec.sr.ht] keys, and the shared keys read
in place.

Documents why skipping GraphQL federation is safe: api.sr.ht federates
every .sr.ht config section with no allow-list, but updateSchema skips
services that fail to serve /query, and the refresh is SIGHUP-driven
rather than a ticker.

docs: design proposal for spec.sr.ht

Reviewable document storage for the self-hosted SourceHut instance: bots
propose, humans review and curate, bots consume the approved text.

Records the four confirmed decisions (proposal-first review gate, own bare
git repos, absorb warren's read plane, thin full-loop v1) and the projects
model that gives cross-space unified search.