feat(clients): iOS + Mac clients — remote access/DDNS, LAN toggle, mobile WS protocol, Plan Mode, App Store readiness

[TYRMars]

Brings the iOS and Mac clients to a shippable state, and closes the gaps that made them
half-connected to the Node runtime. Seven commits, reviewable in order.

What changed

Remote access + DDNS (fb93bf5) — the feature docs/proposals/mobile-ddns.zh-CN.md
describes, landing server-side and on both clients:

• JARVIS_ACCESS_TOKEN bearer gate (packages/server/src/auth.ts): loopback bypasses,
  every /v1 + WS request from elsewhere must present it; a startup WARN fires on a
  non-loopback bind without one.
• New @jarvis/ddns package — Cloudflare / DuckDNS / dyndns2 / Aliyun / DNSPod, public+LAN
  IP discovery, zero-dependency UPnP IGD, and the polling DdnsRuntime — behind
  /v1/ddns/* and the ddns.{status,update,configure} tools. Credentials are persisted
  0600 and scrubbed from every GET.
• iOS: access-token setting, QR pairing (jarvis://pair deep link + camera scan), Bonjour
  LAN discovery, and a remote-access/DDNS configuration screen.
• Web: Settings → Remote Access with the pairing QR.

Mac shell LAN toggle (4e943bf) — the proposal's last open item. A switch in the
Electron shell restarts the embedded server bound to 0.0.0.0 on a stable port (7001,
ephemeral fallback), generates and persists an access token so pairing links keep working,
and starts the Bonjour advertiser. The serve subcommand always advertised; the embedded
path never did, so zero-config discovery was silently broken in the desktop app. The window
keeps talking loopback, which is what keeps /v1/remote/pairing unlockable.

Mobile WS session protocol on Node (b7e5d8c) — the iOS client was written against the
Rust server's protocol; the Node port only spoke user/reset/resume/new/approve/
deny, so start_turn got unknown frame type and reconnect replay never worked. Now:
start_turn, a per-conversation monotonic seq fanned out to all subscribed sockets,
resume {after_seq} tail replay (tail_replay_start/_done, resume_error {evicted}),
cross-socket adoption of pending approvals and ask.* HITL requests (re-prompted on
resume, answerable from the new socket), interrupt, and configure {model}. iOS gained
the HITL question card.

App Store readiness (57d95e2) — icon, PrivacyInfo.xcprivacy (no tracking, no
collection, UserDefaults CA92.1), ITSAppUsesNonExemptEncryption, ATS tightened to
NSAllowsLocalNetworking only, and a step-by-step release section in the iOS README.

Plan Mode + permission modes (acbdf6a) — both clients already sent set_mode /
accept_plan / refine_plan and rendered plan_proposed; the server answered
unknown frame type and /v1/permissions always 503'd. Landed across three layers:

• core: AgentConfig.toolFilter (structural — filtered tools leave the LLM catalogue and
  can't be dispatched if the model guesses a name), Tool.isTerminal honoured by both loops
  (ends the turn, skips the rest of the batch; a denied or failed terminal call does not
  end it), and a plan_proposed event.
• server: per-socket PermissionMode, a RuleApprover in front of the socket's
  ChannelApprover, the plan tool filter installed per turn, accept_plan {post_mode}
  re-briefing the model with the accepted plan, refine_plan {feedback} re-running filtered.
• composition root: a three-scope FilePermissionStore (session in-memory + project
  .jarvis/permissions.json + user ~/.config/jarvis/permissions.json, merged
  user > project > env). JARVIS_PERMISSION_MODE had never actually governed anything.

Two bugs found by running it (feeaff4) — after wiring the permission store I started the
server and looked at the UI:

• GET /v1/conversations 500'd with Cannot read properties of undefined (reading 'length'),
  emptying the sidebar in every client. JsonFileConversationStore.list() skipped directories
  and unparseable files but not a sibling store's file that parses fine —
  channel_instances.json shares the directory and is a JSON array. One neighbour took down
  the whole list. list()/loadEnvelope() now require the conversation shape.
• A default_mode persisted in the permissions file was ignored by the socket, which seeded
  from env only — so persisting a mode changed nothing. The store is now authoritative at
  connect.

Notes for the reviewer

• Approver.willPrompt is a deliberate divergence from the Rust cut. The loop emits
  approval_request before awaiting the approver (documented invariant), which meant auto
  mode flashed an approval sheet on the phone that was dismissed a millisecond later. The new
  optional hook lets the loop skip the prompt when the policy auto-decides;
  approval_decision is still emitted, so the audit trail loses nothing.
• Behavioural change for existing installs: a ~/.config/jarvis/permissions.json written
  by the old Rust build now actually takes effect. On the dev machine here that file pins
  default_mode: auto, so gated tools stop prompting. Worth calling out in release notes.
• Not ported from the Rust design: approval_decision.source plumbed through the core event,
  and the permission_rules_changed broadcast.
• .claude/launch.json was entirely stale (every entry pointed at the decommissioned Rust
  binary and RUST_LOG); replaced with Node entries.

Verification

• pnpm lint clean; pnpm -r typecheck green across 26 packages.
• Tests: core 32 → 38, server 18 → 24 WS, desktop 16 → 21, plus 9 new permission-store and
  20 json-store tests. The only failures are the pre-existing better-sqlite3 ABI mismatch in
  packages/store (built against Electron's NODE_MODULE_VERSION 139, run under Node's 127 —
  rebuilding would break desktop dev).
• iOS: Tests/run-contract-smoke.sh 39/39 (this machine has Command Line Tools only, no full
  Xcode — archives must be produced elsewhere; the README documents the steps).
• Browser: server started against the real store — conversation list 200 with records, mode
  chip reads the persisted mode, no console errors.

🤖 Generated with Claude Code