Strata design: the data sovereignty case (refs #63) 82504d09aefe

## 1a. The driving case: data sovereignty

UK Government work requires data to be kept on UK shores. On GitLab SaaS

that meant waiting for GitLab to build UK data centres, and it was still

unclear where runners kept their data, so the runners were self-hosted.

Strata answers that for repositories: they live in the customer's own

bucket, in their region, encrypted with their own KMS key. A sovereign

forge needs the same for everything else:

- **Flow artifacts, logs and caches** in the customer's bucket. Today

  artifacts are kept in the hub's store and logs in its database. This is

  the next gap after Strata.

- **Forge records** (issues, proposals, reviews) in a database in the

  customer's region.

- **Keys held by the customer:** KMS for storage, developers' own keys

  for signing.

The model to aim for is **control plane anywhere, data plane in the

customer's account**:

- **Content is never trusted to the operator.** It is hash-verified and

  signed, so it stays tamper-evident whoever runs the hub.

- **Crypto-shredding.** Revoking the customer's KMS key makes the data

  unreadable everywhere, including backups. That is a clean exit and

  deletion guarantee.

- **The customer audits the vendor.** Every read the hub makes appears in

  the customer's own CloudTrail or GCS audit logs.

- **Rendering stays in-region.** Rendering code for the browser needs

  plaintext, so a store-and-render node runs inside the customer's

  account, and only orchestration and the UI shell run outside it.