ACTIVITY-WP-0043-T06: single-repo owner-return pickup caller in the worker

Precondition 3 of the activation plan. New bounded operation
owner_return_pickup (state-hub-owner-return/pickup), executed by the existing
execute_bounded_operation activity and operator-triggered via the ops console
trigger with confirm_side_effect; no schedule, definition stays disabled.

The caller reads an operator-supplied C-25 checker artefact pinned by sha256
(the checker needs a local checkout and cannot run in the worker), requires a
full-SHA source_revision on the report and every C-25 finding, refuses failed
or incomplete collection, binds build_current_tasks to that SHA (Forge HEAD
verified), runs the State Hub planner vendored byte-identically from
state-hub 150cb0b, and submits only reviewable candidates under
ACTIVITY_CORE_OWNER_RETURN_PICKUP_ENABLED. Evidence is IDs/counts only.

build_current_tasks now refuses a report without source_revision and names
source_revision_reason when it is null.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 692292@bnt-lap001
Assistant-Session: 89c7d8e8-e1b3-47eb-9411-a0ab227fca2f

docs/owner-return-pickup-activation-plan.md

@@ -13,6 +13,8 @@ STATE-WP-0094-T03. Nothing below has been applied.
 | Repository grant | v1, `allowed_paths: [workplans]`, commits 1..1, `publish: false` |
 | Adapter | `activity_core.owner_return_pickup.submit_owner_returns(session, candidates, collection_complete=...)` |
 | Gate | env `ACTIVITY_CORE_OWNER_RETURN_PICKUP_ENABLED` (unset = refuse before any write) |
+| Caller | `activity_core.owner_return_runner.run_owner_return_pickup`, bounded operation `owner_return_pickup` (source `state-hub-owner-return` / `pickup`), ACTIVITY-WP-0043-T06 |
+| Planner | State Hub `scripts/owner_return_handoff.py`, vendored byte-identically from state-hub `150cb0b` as `activity_core/vendored/state_hub_owner_return_handoff.py` (drift test when state-hub is checked out) |
 
 ## Preconditions (all required before activation)
 
@@ -25,8 +27,77 @@ STATE-WP-0094-T03. Nothing below has been applied.
    (ACTIVITY-WP-0043-T05); the C-25 caller must pass the scanned commit SHA.
 3. The caller runs inside the existing supported runner (Custodian dependency
    monitor / established Activity Core worker); no new schedule is introduced.
+   **Built at source level (ACTIVITY-WP-0043-T06)**, see "Caller wiring" below;
+   not deployed.
 4. Founder review of this plan and of the definition/grant above.
 
+## Caller wiring (precondition 3)
+
+The caller is the code-registered bounded operation `owner_return_pickup`
+executed by the existing `RunActivityWorkflow` → `execute_bounded_operation`
+activity on `orchestrator-tq` (single Temporal attempt, 300 s). It is exposed
+like every other operator-run bounded operation: the context source sits on a
+definition and the operator fires it with
+`POST /ops/automations/{id}/trigger` + `confirm_side_effect: true` (the
+`owner_return_pickup` side-effect marker forces the confirmation). Manual
+trigger does not require `enabled: true`; the definition stays disabled, so
+there is no schedule.
+
+Context-source stanza (exactly one repository; params validated at parse):
+
+```yaml
+context_sources:
+  - type: state-hub-owner-return
+    query: pickup
+    operation: owner_return_pickup
+    required: true
+    bind_to: context.owner_return
+    params:
+      target_repo: <one repo slug>
+      report_file: activity-core://owner-return/<repo>-c25.json   # worker-mounted
+      report_sha256: <sha256 of that artefact>
+      submit: false                       # true only under the activation flag
+      # optional: expected_source_revision: <40-hex>
+      # optional: predecessor_repos: {"STATE-WP-": state-hub}
+```
+
+How the C-25 report and SHA are obtained: **operator-supplied artefact.** The
+checker reads workplans from the repository's registered `local_path` and gets
+`source_revision` from `git` in that tree; the worker has no checkouts
+(ADR-002), no checker image, and Repo Manager's C-rule engine has no C-25. So
+the operator runs `consistency_check.py --json` for the repository (clean
+`workplans/` so `source_revision` is a full SHA), places the JSON at the mounted
+path (a `--all` list is accepted; exactly one object must match `target_repo`), and pins its sha256 in the reviewed params. The caller then refuses
+unless: the digest matches; `repo_slug` equals `target_repo`;
+`source_revision` (report and every C-25 finding) is the same full 40-hex SHA
+(`null` refuses with `source_revision_reason`); `result != error`; no C-25
+"reply collection ... is incomplete" finding exists; and `build_current_tasks`
+confirms via Forge that the SHA is still the default-branch HEAD. Planner
+candidates must echo the same repo/revision. Only `reviewable` candidates reach
+`submit_owner_returns`; existing ops runs are not fed to the planner, so
+deduplication stays server-side and a re-run reports `duplicate` receipts.
+
+Evidence (bound to `context.owner_return`, IDs/counts only): planner input
+(report result, revision, finding/message counts, task record IDs,
+counterparts, completeness, `current_tasks` schema/revision/count, HEAD
+verified), planner output (dispositions, stop reasons, candidate IDs) and
+receipts (`triggering_event_id`, `idempotency_key`, `status`, `ops_run_id`,
+`state`). Tests: `tests/test_owner_return_runner.py`.
+
+Remaining gaps before the first trial:
+
+- No in-cluster report producer: the artefact is produced on the workstation
+  and mounted by the operator. A Forge-content C-25 (Repo Manager C-rule engine
+  or a checker mode reading `ref=<sha>`) would remove that step.
+- Completeness is inferred from the absence of the C-25 "incomplete" WARN
+  text; the checker JSON has no structured per-counterpart reply count / last
+  page field, which the evidence section below asks for.
+- Forge reads are unauthenticated (public repositories only); a private target
+  needs a reviewed read-credential route.
+- The definition does not yet carry the stanza: adding it (with the chosen
+  repository and artefact digest) and mounting the artefact are part of the
+  founder-reviewed activation, as is the flag below.
+
 ## Exactly what would be enabled
 
 1. Set `ACTIVITY_CORE_OWNER_RETURN_PICKUP_ENABLED=true` on the single process