Accept WP-0012-T02: repo identification and Phase-provenance fields

Confirmed live against forgejo.coulomb.social before deciding rather
than assuming: repo ids are real and stable (target-revenue is 103),
but no instance-level hub identity exists (no nodeinfo endpoint), so
the hub identifier has to be minted, not read from Forgejo.

Decided: milestone_release gains required repo_hub/repo_hub_uri/
repo_id/repo_name; phase.base_phase_id is optional, absent for a
first-ever Phase. The hub-to-URI mapping is hosted Trust Service data
(a new table, parallel to licensor_identities), not a file in this
framework repo, per the maintainer's steer that target-revenue must
stay the generic framework rather than carry a specific deployment's
repo list. Backfilling the three example manifests is deferred to
after T03/T04/T05, since the schema change is shared across all three.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

workplans/TREV-WP-0012-phase-provenance-and-policy-modeling.md

@@ -75,9 +75,11 @@ WP-0014-T01 rather than something to assume while building that UI.
 
 ```task
 id: TREV-WP-0012-T02
-status: todo
+status: done
 priority: high
 human_accept_required: true
+human_accepted_by: Bernd
+human_accepted_at: "2026-07-30"
 state_hub_task_id: "1d888dc7-360d-4ee5-8f4c-d1173670b0f7"
 ```
 
@@ -102,6 +104,46 @@ breaking a Phase's provenance link. Concretely decide and record:
   existing pilot-candidate example manifests, or only required going
   forward.
 
+**Result (accepted 2026-07-30):** Grounded against the real Forgejo
+instance before deciding, not assumed — confirmed live that
+`forgejo.coulomb.social` assigns every repo a stable numeric id
+(`target-revenue` is `103`, via `GET /api/v1/repos/coulomb/target-revenue`)
+that survives renames, and confirmed it has **no** instance-level identity
+endpoint (`/api/v1/nodeinfo` → 404, `/api/v1/version` returns only a
+version string) — so unlike the repo id, a hub identifier is necessarily
+something this project mints, not something Forgejo already provides.
+
+Decided:
+
+- `phase.milestone_release` gains four **required** fields: `repo_hub`
+  (a stable slug, e.g. `"forgejo-coulomb"`), `repo_hub_uri` (the Forgejo
+  service URL, e.g. `"https://forgejo.coulomb.social"`), `repo_id`
+  (Forgejo's own numeric repo id), `repo_name` (`"owner/repo"` slug).
+  Required immediately, not merely recommended — no grace period, unlike
+  `target_basis`'s current recommended-only status.
+- `phase.base_phase_id` (optional, `trsl:phase:...` pattern) references
+  a prior Phase for a successive Phase; simply **absent** for a
+  first-ever Phase — no sentinel value, matching how
+  `ledger_entry.schema.json`'s `reverses` is already optional-only-when-
+  applicable.
+- **Important refinement from the maintainer's own steer**: the
+  `repo_hub` → `repo_hub_uri` mapping is *not* static data checked into
+  this repo. `target-revenue` is the generic framework, not a specific
+  deployment's list of repos it happens to monetize — that mapping is
+  operational data owned by the **hosted Trust Service** (a new table,
+  analogous to `licensor_identities`, auto-populated the first time a hub
+  is seen), never a file in this git repo. A Phase Manifest stays fully
+  self-describing and offline-verifiable regardless (it carries
+  `repo_hub_uri`/`repo_name` directly at registration time, per use case
+  9) — the hosted table exists purely as an admin/repair convenience if
+  a hub's URI ever needs correcting after the fact, not a validation
+  dependency.
+- The three existing example manifests will be backfilled — deferred
+  until after T03/T04 and the T05 spec addendum, since the schema change
+  is shared across all three decision tasks and the maintainer's own
+  process (item f, chat 2026-07-30) calls for the addendum to be
+  discussed before any implementation, including this backfill.
+
 ```task
 id: TREV-WP-0012-T03
 status: todo