Mac Access: make Workbench use the shared runtime without dual ownership

[100yenadmin]

Parent epic: #698
Depends on: #700, #701, #702, and #703.
Related: #687 and #688.

Context

Workbench currently discovers and manages its bundled connector through evaosNativeCompanionStatus.ts. Once Mac Access exists, Workbench must become a client of the same stable local runtime. Running both products must never create two permission owners, listeners, grants, lifecycle managers, or contradictory readiness states.

Required change

Add a signed/authenticated local discovery and client path so Workbench uses Mac Access when it is installed. Retain a bounded migration fallback for Workbench-only users, but enforce a single active connector leader.

Integration rules

• Mac Access owns stable app/helper identity, TCC-facing status, Keychain material, outbound broker channel, local audit writes, and connector-core lifecycle.
• Workbench requests status/actions through the authenticated local client contract and continues to protect renderer boundaries through evaosNativeCompanionBridge.ts.
• Workbench passes or selects only broker-authorized scope from P0: Workbench must display and control the broker-selected Mac binding #687/P0: agent Mac-control tools must consume the broker-selected customer/grant scope #688; Mac Access revalidates it against its active binding.
• If Mac Access is absent, the existing Workbench fallback may run during migration. If Mac Access is installed or takes leadership, Workbench must stop/relinquish its connector cleanly before becoming a client.
• Conflicting owner, stale LaunchAgent, mismatched core digest, or incompatible schema produces one typed blocker and guided repair. Never race two listeners or silently choose one.

Acceptance criteria

1. Workbench discovers a valid Mac Access installation by signed identity and authenticated local protocol, not app-name lookup or an unauthenticated port probe.
2. With Mac Access active, Workbench does not start an embedded connector, create a second grant, request duplicate TCC permissions, or bind a competing listener.
3. Workbench and Mac Access show the same readiness, selected account/device/grant/runtime scope, access mode, blocker reason, freshness, and audit/correlation IDs.
4. Workbench agent tools consume only the broker-selected binding and Mac Access rejects any mismatch.
5. Startup orders are tested: Mac Access first, Workbench first, simultaneous start, either app crash, either app upgrade, logout/login, and machine restart.
6. Migration from the Workbench-managed LaunchAgent preserves safe state, removes stale ownership, and never leaves an orphan remote-control path.
7. Downgrading Workbench or Mac Access fails closed on schema/digest incompatibility and provides a reversible repair path.
8. Existing Workbench IPC secret-guard tests, native-companion tests, functional smoke, and Mac-control doctor remain green.
9. The Workbench UI links to Mac Access for permission and access-mode changes rather than pretending the renderer owns them.

Source references

• packages/desktop/src/process/services/evaosNativeCompanionStatus.ts
• packages/desktop/src/process/bridge/evaosNativeCompanionBridge.ts
• packages/desktop/src/common/evaos/nativeCompanionBoundary.ts
• packages/desktop/src/process/services/evaosBrokerSession.ts
• packages/desktop/src/process/resources/builtinMcp/evaosMacControlServer.ts
• scripts/evaosMacControlDoctor.js

Testing plan

• local protocol authentication and signature/identity fixtures;
• single-leader race tests;
• selected-binding mismatch and stale-proof tests;
• startup/crash/upgrade/downgrade matrix;
• Workbench functional smoke and Mac-control doctor;
• exact installed-app coexistence proof using signed candidates.

Rollback

Disable Mac Access discovery behind the migration flag and return Workbench to its existing connector fallback. Revoke test grants and verify no Mac Access process/listener remains. Do not alter the shipped v2.1.36 artifact.

Non-goals

• no Workbench visual redesign;
• no new renderer trust authority;
• no v2.1.36 release change;
• no public release or customer rollout.