CUST-WP-0055 T05: workplan-first progress scope in sinks and resolvers

Prefer workplan_id in State Hub progress writes while dual-writing
workstream_id for wire-compat. Extend schedule_health, evidence/report
sinks, phase5 checks, k8s triage prose, and SCOPE terminology.

SCOPE.md

@@ -55,7 +55,7 @@ The two evaluation modes:
   scheduled datetime; event-type subscription via NATS; manual one-shot API
   trigger; one-shot schedule smoke tests for recurring definitions.
 - **Context resolution adapters**: repo-scoping (repository capability queries),
-  State Hub (domain/workstream state, SBOM status, daily triage digest, coding
+  State Hub (domain/workplan state, SBOM status, daily triage digest, coding
   retro read model), and ops inventory (bounded HTTP/HTTPS probes of a
   non-secret service inventory). The adapter registry is extensible for other
   sources.
@@ -218,7 +218,7 @@ workplan explicitly rehomes execution responsibility.
 One boundary nuance is now explicit: activity-core may post State Hub progress
 events as a configured report or evidence sink. That is acceptable because it
 records the result of an activity-core activation; it is not ownership of State
-Hub state, task lifecycle, or workstream planning.
+Hub state, task lifecycle, or workplan planning.
 
 The main drift risk is convenience creep: adding direct task tracking,
 project-phase state, or bespoke operational scripts because the Temporal
@@ -277,7 +277,7 @@ new one-off control paths.
 - **Coordinates with**: the state hub delegates maintenance automations to
   activity-core by publishing lifecycle events or by being resolved as context.
   activity-core may post progress events as report/evidence outputs, but it
-  does not own State Hub task/workstream state.
+  does not own State Hub task/workplan state.
 
 ---