fix(witan): route inject-context through the deployment for a remote target

[blarghmatey]

What are the relevant tickets?

N/A — tracked internally as tk-witan-hook-context-reads-the-local-store-on-a-de-dfb2c9 in the witan multi-user service deployment project.

Description (What does it do?)

• witan hook context (the UserPromptSubmit hook every agent session runs) called cfg_module.load() and handed graph_uri straight to a raw OmnigraphClient, never consulting load_remote_config().
• A remote_url-only deployment target has no server field, so graph_uri fell through to the local default (~/.local/share/witan/graph.omni) — the same split-brain agent-kit#261 fixed for witan serve, still live on this path.
• Every new agent session on a deployed target opened with context (active projects, ready tasks) read off the laptop, while the same session's tool calls wrote the deployment.
• Fix: route the remote case through the tool-calling proxy _srv() already builds (workflow_project_list/task_ready/workflow_session_list), matching how session-checkpoint already reaches the deployment.
• Trade-off: branch-linked task association (the ## In-Flight Branch section) and stale-repo-case detection have no remote-tool equivalent yet, so they degrade to empty/false for a remote target rather than lie about it — recorded via --debug, never silently.

How can this be tested?

• pytest tests/test_context.py: 27/27 pass. Updated test_inject_context_cli_survives_an_unreachable_deployment, which had pinned the old local-store-read behavior as expected — it now exercises the new tool-calling proxy's failure path instead, asserting the hook still degrades to empty output rather than raising.
• Full witan suite: 887 passed, 6 failed on this branch. Ran the identical suite on a clean main worktree (same shared venv) as a baseline: also 887 passed, 6 failed — same total, and 5 of the 6 failing tests are identical (test_contracts.py x4, test_setup_cmd.py x1; a known shared-venv witan-code import contamination, unrelated to these files). The 6th differs per run on both branches — test_elicit.py::test_supersede_confirmed_links failed here, test_event_loop_blocking.py::test_the_known_async_tools_are_still_async_and_still_covered[workflow_project_advance] failed on the main baseline run — each passes in isolation on both branches, so this is pre-existing order-dependent flakiness, not something this diff introduced.
• ruff check/ruff format: no new lint debt vs main (8 pre-existing errors, unchanged).
• Not yet verified against a live deployed target's pod log (the same method that confirmed fix(witan): serve the deployed graph instead of silently opening the local store #261's fix). Recommend a follow-up spot-check: run witan hook context --debug from a checkout matching a deployed target, then confirm the corresponding workflow_project_list/task_ready calls appear in that target's data-tier log under the caller's own actor.

Additional Context

Part of the wp-witan-multi-user-service-deployment-dcf6ee project's phase-exit hardening — this is the same class of split-brain bug as #261, found while re-verifying that project's multi-user readiness.

[Copilot]

Pull request overview

Routes context injection through the remote deployment, preventing accidental reads from the local graph.

Changes:

• Adds remote context retrieval through MCP tools.
• Selects remote or local context paths from configuration.
• Updates unreachable-deployment coverage.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
witan/context.py	Adds shared rendering and remote reads.
witan/cli/hooks.py	Routes remote targets through the proxy.
tests/test_context.py	Updates remote failure-path coverage.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.