docs(ACTIVITY-WP-0014): close T05 in-repo; split beachhead adoption to WP-0015

Idempotent-writes half of T05 is done in-repo; the externally-blocked endpoint
adoption + actcore-state-hub-bridge proxy retirement move to ACTIVITY-WP-0015
(blocked on the state-hub beachhead) so WP-0014 can close on completed work.

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

workplans/ACTIVITY-WP-0014-schedule-misfire-robustness.md

@@ -155,7 +155,7 @@ guidance in `docs/runbook.md`. Depends on T01 (confirm) and T02 (modes exist).
 
 ```task
 id: ACTIVITY-WP-0014-T05
-status: progress
+status: done
 priority: high
 state_hub_task_id: "b7e5b877-1b09-421c-a04e-78f785dc00a1"
 ```
@@ -179,11 +179,11 @@ activity-core's only responsibilities under this model are thin:
   error instead of hard-failing), so the guarantee lives on the keyed write, not
   a live read. Tests in `tests/test_state_hub_write.py`; documented in
   `docs/runbook.md`.
-- **Adopt the beachhead endpoint (blocked on state-hub):** keep `STATE_HUB_URL`
-  pointed at the local beachhead, and **retire the bespoke
-  `actcore-state-hub-bridge` proxy** (the inline `hostNetwork` proxy in
-  `k8s/railiance/20-runtime.yaml`) once the state-hub-owned beachhead exists — it
-  is a primitive precursor of the beachhead and should not be extended here.
+- **Adopt the beachhead endpoint — MOVED to [[ACTIVITY-WP-0015]]:** pointing
+  `STATE_HUB_URL` at the local beachhead and retiring the bespoke
+  `actcore-state-hub-bridge` proxy depend on the state-hub beachhead existing
+  first. Split into WP-0015 (status `blocked`) so this workplan can close on its
+  completed in-repo work rather than waiting on an external capability.
 
-Blocked on the state-hub beachhead capability for the second item; the idempotent
--writes item can proceed independently.
+T05 is done as far as activity-core can act now; the external-dependent adoption
+lives in WP-0015.

workplans/ACTIVITY-WP-0015-adopt-statehub-beachhead-endpoint.md

@@ -0,0 +1,54 @@
+---
+id: ACTIVITY-WP-0015
+type: workplan
+title: "Adopt State Hub Beachhead Endpoint"
+domain: infotech
+repo: activity-core
+status: blocked
+owner: claude
+topic_slug: activity-core
+created: "2026-06-24"
+updated: "2026-06-24"
+state_hub_workstream_id: ""
+---
+
+# Adopt State Hub Beachhead Endpoint
+
+Carries the **blocked remainder** of [[ACTIVITY-WP-0014]] T05. The in-repo half
+(idempotency-keyed State Hub writes) shipped in WP-0014; this workplan is the
+client-side adoption that depends on the state-hub-owned **beachhead** capability
+(per-machine read cache + write outbox) existing first.
+
+**Blocked on:** the state-hub beachhead (proposal sent to the `state-hub` agent,
+2026-06-23). Do not build queue/cache logic in activity-core — see
+[[statehub-beachhead-principle]].
+
+## Point STATE_HUB_URL at the beachhead
+
+```task
+id: ACTIVITY-WP-0015-T01
+status: wait
+priority: medium
+state_hub_task_id: ""
+```
+
+Once the state-hub beachhead exposes a local endpoint, point activity-core's
+`STATE_HUB_URL` (and the railiance runtime config) at it and verify reads are
+served from cache and writes are queued/flushed correctly when central State Hub
+is unreachable. Confirm idempotency-keyed writes dedup on flush (no duplicate
+`daily_triage`/progress events).
+
+## Retire the bespoke actcore-state-hub-bridge proxy
+
+```task
+id: ACTIVITY-WP-0015-T02
+status: wait
+priority: medium
+state_hub_task_id: ""
+```
+
+Remove the inline `hostNetwork` HTTP proxy `actcore-state-hub-bridge` from
+`k8s/railiance/20-runtime.yaml` — it is a primitive precursor of the beachhead
+and should be replaced by the state-hub-owned component, not extended. Re-verify
+the daily triage end-to-end after cutover, including an overnight scheduled run
+while the workstation is asleep (the original failure condition).