Complete native Arbiter transport and secure key migration

[tomvaillant]

Goal

Complete the native Arbiter integration after task #61 was blocked by post-recovery security and wiring findings.

Required work

• Wire a production Arbiter client into Spotlight browse, read, report, and reviewed create/progress flows; offline renderers remain offline consumers of saved raw responses.
• Ship the client in the distributed plugin and update the payload allowlist/generator contract.
• Use a Spotlight-owned secure keychain/secret-store bridge. Do not invoke the retiring Navigator CLI at runtime and never expose the key in argv, logs, prompts, or case files. The existing Navigator keyring entry may be migrated locally without revealing its value.
• Close SSRF/private numeric/DNS-alias validation, API path traversal, case-directory symlink containment, sensitive-mode preflight egress, and run_create input/output containment.
• Preserve exact Arbiter request shapes, credit/confirmation/retry rules, raw-response evidence, and offline report behavior.

Acceptance criteria

• Production workflows call the native client; no documentation-only transport remains.
• Distributed plugin override preflight works without ModuleNotFoundError.
• API base and request paths fail closed for unsafe hosts, schemes, ports, dot segments, encoded traversal, and private/reserved targets.
• Sensitive mode makes no Arbiter network request, including preflight smoke checks.
• Every file-backed request/input/output is contained under the case research directory and rejects symlink escapes.
• Existing keyring material can be used through a Spotlight-owned secret boundary without revealing the value or depending on Navigator CLI execution.
• Focused hostile-input, mocked HTTP, plugin, full-suite, review, and security-audit gates pass.

Non-goals

• Do not create or finalize a real Arbiter study during implementation.
• Do not retire Navigator Skills, Workflows, or the Navigator repository in this task.