STATE-WP-0062 T5: docs, first-party↔repo test, mark workplan finished

- Add /docs/services reference (two-dimension model, persistence, API) and a
  pointer note from /docs/tpsc; add it to the Reference nav.
- Add a test asserting first_party.repo_slug resolves to a managed_repos FK
  (8 services tests green).
- Mark STATE-WP-0062 tasks done / status finished.

Known classes seeded in the live catalog via the API (Gitea, Postgres as
self-hosted/third-party; State Hub as self-hosted/first-party at Level 2).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

dashboard/src/docs/services.md

@@ -0,0 +1,54 @@
+---
+title: Service Catalog — Reference
+---
+
+# Service Catalog (two dimensions)
+
+Every service coulomb consumes or operates is classified along **two independent
+dimensions**, so four classes fall out of their product:
+
+| | **third-party** (not dev-responsible) | **first-party** (dev-responsible) |
+|---|---|---|
+| **cloud-hosted** (consumed) | SaaS / APIs — the classic [TPSC](/docs/tpsc) | a coulomb service deployed to a cloud |
+| **self-hosted** (operated) | OSS coulomb runs (Gitea, Postgres…) | a coulomb service on coulomb infra |
+
+- **Hosting** — `self_hosted` (coulomb operates the service) vs `cloud_hosted`
+  (coulomb consumes someone else's running service).
+- **Development** — `first_party` (coulomb is development-responsible) vs
+  `third_party` (coulomb is not).
+
+## Persistence
+
+A common **`service_catalog`** core table holds the shared fields
+(`slug`, `name`, `owner_or_provider`, `category`, `status`, `hosting_type`,
+`development_type`, `maturity_level`). Dimension-specific data lives in 1:1
+extension tables that **compose** — a self-hosted first-party service carries
+both the self-hosted *and* first-party extensions:
+
+| Extension | Keyed on | Holds |
+|---|---|---|
+| `service_third_party` | `development_type = third_party` | upstream packages, support/service contacts, source, license, pricing |
+| `service_first_party` | `development_type = first_party` | internal dev repo (`managed_repos` FK), owning domain |
+| `service_cloud` | `hosting_type = cloud_hosted` | GDPR maturity, DPA, ToS/privacy, data-processing regions, retention |
+| `service_self_hosted` | `hosting_type = self_hosted` | three-helix instance/host, deployment & runbook refs, upstream OSS project |
+
+`maturity_level` (1 · Core → 2 · Standard → 3 · Mature) tracks a service against
+the [Service DoM](/policy/service-dom).
+
+## API
+
+- `GET /services/catalog?hosting_type=&development_type=&maturity_level=&status=`
+  — filtered list; each row includes its applicable extensions.
+- `GET /services/{slug}` — one service with extensions.
+- `POST /services/catalog` — upsert by slug; pass `first_party.repo_slug` to link
+  the internal dev repo.
+
+The dashboard **Services** section renders three views over this catalog:
+[Third Party](/tpsc), [First Party](/services/first-party), and
+[Self Hosted](/services/self-hosted).
+
+## Migration & back-compat
+
+Existing TPSC catalog rows migrated into `service_catalog` as
+`(cloud_hosted, third_party)`, reusing their ids so `tpsc_entries.catalog_id`
+keep resolving. The `/tpsc/*` endpoints and `tpsc.yaml` ingestion are unchanged.

dashboard/src/docs/tpsc.md

@@ -7,6 +7,11 @@ title: Third-Party Services Catalog (TPSC)
 The TPSC tracks external service dependencies (APIs, SaaS, CLIs) across all
 registered repos — complementing the SBOM for package dependencies.
 
+> **Now part of the broader service catalog.** TPSC is the `cloud_hosted` +
+> `third_party` quadrant of the two-dimension [service catalog](/docs/services).
+> Catalog rows have migrated into `service_catalog`; the `/tpsc/*` endpoints and
+> per-repo `tpsc.yaml` dependency snapshots continue to work unchanged.
+
 ---
 
 ## Why TPSC?