feat: adopt canon 0.4.0-0.6.0 — EvidenceBasis is canon, uses_provisions is canon

Both demands were accepted. Adopting what landed.

EVIDENCE BASIS IS NOW ITC-GOV CANON (0.4.0)
tools/basis.py reads infospace/models/governance/evidence-basis.yaml instead of
defining its own vocabulary — same discipline we already applied to the
capability catalog. Two semantic changes came back that we did not have:

- estimated and assumed are peers in tier "judgement". We had them separately
  ranked, which asserted a difference the canon does not.
- derived belongs to no tier at all; asking for its tier before resolving it is
  now an error rather than a silent rank.

Tier membership is read from tiers[].members, not bases[].tier: the latter
labels invoiced/measured/quoted all as "evidenced" while the tier list splits
them across "observed" and "quoted". tiers[] is authoritative; reported upstream.

USES_PROVISIONS IS NOW CANON (0.5.0, CAP-R11)
Dropped the proposed_extensions marker. Renamed relation "uses" to "may_use" per
their migration note. tools/capability.py now enforces CAP-R11: relation must be
depends_on or may_use, a provider must be named, and a depends_on entry MUST be
declared between those capabilities in the catalog. data.backup gained catalog
may_use: security.secrets from our restatement, so our entry now checks out.

Also in 0.4.0: §10.3 changed so a joinable consumer record counts as promotion
proof, met by our restatement; ITC-CAP is now 0.4.0 / canon 0.6.0, status draft.
Record and tests updated to those versions.

196 tests pass.

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

data/capability/platform-audit-storage.json

@@ -3,9 +3,11 @@
   "record_scope": "operational",
   "canon": {
     "model": "ITC-CAP",
-    "model_version": "0.2.0",
-    "canon_version": "0.3.0",
-    "catalog": "info-tech-canon/infospace/models/capability/capabilities.yaml"
+    "model_version": "0.4.0",
+    "canon_version": "0.6.0",
+    "status": "draft",
+    "catalog": "info-tech-canon/infospace/models/capability/capabilities.yaml",
+    "evidence_basis_catalog": "info-tech-canon/infospace/models/governance/evidence-basis.yaml"
   },
   "record_id": "capability-case:platform-audit-storage:2026-08",
   "created_at": "2026-08-15T00:00:00Z",
@@ -197,7 +199,7 @@
         {
           "capability": "security.secrets",
           "provider": "OpenBao / external-secrets on reef-railiance",
-          "relation": "uses",
+          "relation": "may_use",
           "note": "ClusterSecretStore openbao-backup-object-storage; ExternalSecret synced to databases/platform-pg-backup-s3. Not a consumption row: no purchased platform capacity is bought here, another capability is used.",
           "evidence_basis": "measured",
           "observed_at": "2026-08-14"
@@ -278,14 +280,6 @@
     "The requirement asks for data.backup at D5; the provision is D4. Closing it needs a drill cadence, an emitted wal_archive_gap_minutes, and more than one backup.",
     "Class I consumption is unknown on both provisions. resource-control does not meter tokens against a provision yet.",
     "Class H on the data.backup provision is unknown: effort was spent and not recorded. A time record starts in 2026-09.",
-    "No invoiced basis exists anywhere in this record. The first booked Scaleway cost from fin-hub (FIN-WP-0004) would be the first.",
-    "provisions[].uses_provisions is a proposed extension, not canon. It replaced a consumes:P row for credential custody, which was the wrong kind: P is purchased platform capacity, and using security.secrets buys none."
-  ],
-  "proposed_extensions": {
-    "note": "uses_provisions is NOT canon. ITC-CAP 0.2.0 declares capability-to-capability relations and landscape-to-capability relations, but no provision-to-provision relation. info-tech-canon identified the gap on 2026-08-15 and asked us to file it as demand rather than have them invent the field from a message.",
-    "fields": [
-      "provisions[].uses_provisions"
-    ],
-    "demand": "info-tech-canon/demand/ProvisionRelationships.md"
-  }
+    "No invoiced basis exists anywhere in this record. The first booked Scaleway cost from fin-hub (FIN-WP-0004) would be the first."
+  ]
 }