feat(portfolio): fold in RAILIANCE-WP-0016 apps-pg evidence

First delegated evidence from RESOURCE-WP-0003-T04 to land. railiance-platform
delivered apps-pg capacity, utilization, consumers, and the apps-pg-dbbytes-v1
allocation driver, and correctly delivered no EUR.

- data/resources/apps-pg.json: real capacity; allocation unattributed -> shared
  under apps-pg-dbbytes-v1; second consumer vergabe-teilnahme registered
- data/control-cycle/apps-pg-2026-09-base.json: first operational control-cycle
  record in the repository
- examples/control-cycle/apps-pg-*.json retired; the invented fixture collided
  with the real record's identifier
- data/portfolio-coverage-2026-08-14.json: gap marked delivered with three
  residual unknowns still open

The real evidence exposed a design gap in the T05 schema: v0.1 required a number
for every cost field, so recording genuine usage without a booked cost meant
inventing one. Schema 0.2 permits null costs, null unattributed_eur, a technical
unattributed_share, and null measurements. Null is unknown, never zero; an
unknown component makes the total null rather than the sum of the known parts;
and the comparator classifies unknown amounts as data_quality instead of
computing a variance. Existing 0.1 records are not rewritten.

apps-pg is now measured (idle at 5.8% of volume) and attributed, and remains
unpriced: delivered technical evidence does not create a booked cost.

86 tests pass.

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

docs/forecast-actual-control.md

@@ -98,10 +98,41 @@ make control-cycle FORECAST=examples/control-cycle/storage-forecast.json \
   ACTUAL=examples/control-cycle/storage-actual.json
 ```
 
-The examples cover storage, `reef-railiance` cluster compute, and the shared
-`apps-pg` service. Their numbers are illustrative contract fixtures, not booked
-facts. Operational records replace their evidence references after the owner
-workplans publish observations.
+The examples cover storage and `reef-railiance` cluster compute. Their numbers
+are illustrative contract fixtures, not booked facts. Operational records
+replace them once the owner workplans publish observations — the illustrative
+`apps-pg` pair was retired on 2026-08-14 when `RAILIANCE-WP-0016` delivered the
+real one to `data/control-cycle/apps-pg-2026-09-base.json`.
+
+Illustrative fixtures live in `examples/control-cycle/`; operational records
+live in `data/control-cycle/` and must cite the authoritative repository
+evidence they came from and state their uncertainty. The validator enforces
+both.
+
+### Schema 0.2 — unknown is not zero
+
+Real evidence arrives incomplete. `RAILIANCE-WP-0016` supplied apps-pg
+capacity, utilization, consumers, and an allocation driver, and correctly
+supplied no EUR: the host bill belongs to `resource:hosteurope:railiance01`,
+whose price is still unknown. Schema 0.1 could not express that — every cost
+field required a number, so the only way to record real usage was to invent a
+cost.
+
+Schema 0.2 permits `null` for each cost component, for `unattributed_eur`, and
+for any measurement value, and adds `unattributed_share` so a shared-cost
+residual can be recorded from technical evidence before any EUR exists. The
+rules:
+
+- `null` means unknown or unbounded, never zero;
+- if any cost component is unknown, `total` is `null` — never the sum of the
+  parts that happen to be known;
+- the comparator returns `status: "unknown"` for that component and classifies
+  it `data_quality`, overriding any explicit attribution, because a missing
+  amount is an evidence gap rather than a price or labour movement;
+- known components still compute their variance alongside unknown ones.
+
+Existing 0.1 records stay valid and are never rewritten. Immutability applies
+to the record, not to the schema, so `schema_version` accepts both.
 
 ## Variance attribution