P3: Move evaos-desktop-bridge modules into evaOS-GUI after Mac-control release

[100yenadmin]

Summary

Track the post-release bridge ownership cleanup: move the currently bundled evaos-desktop-bridge modules into evaOS-GUI so the legacy bridge repo can be deprecated without changing the active #402 release proof lane.

Scope

• Inventory the currently bundled bridge resources used by Workbench Mac control.
• Define the module boundary inside evaOS-GUI for connector service, customer Mac control, audit, stop/revoke, and kill-switch helpers.
• Add source/build/test ownership in this repo.
• Preserve the packaged resource shape or provide a migration path with signed installed-app proof.
• Deprecate the legacy evaos-desktop-bridge repo after the new module path is proven.

Non-goals

• Do not block P0: v2.1.22 installed app blocks Mac control and pairing prompt #402 or the current first-party no-code Mac-control release.
• Do not change release/signing workflow as part of this tracker.
• Do not remove exported pairing fallback until external-agent/recovery policy is replaced.

Acceptance Criteria

• Workbench builds and packages bridge modules from evaOS-GUI source.
• Local OpenClaw, VM OpenClaw, and Hermes smokes still pass through the same connector contract.
• Signed installed app proof confirms helper path, active LaunchAgent path, stop/revoke, and kill-switch fail-closed.
• Legacy repo has a documented deprecation/archival plan.

Refs #402.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• Track bridge modularization follow-up after release stabilization #443

🔗 Related PRs

#416 - Fix Mac control connector-service ready reconciliation [merged]
#417 - Fix Mac pairing reconnect session gate [merged]
#449 - Fix legacy app stale owner proof path [merged]
#462 - [codex] Document Workbench release proof lanes [merged]
#476 - Harden installed Mac-control proof scope [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[100yenadmin]

Post-release boundary for Mac Control Contract Unification

This issue remains intentionally post-release / post-stabilization.

Tracker: #480

The current sprint must first stabilize the contract and proof surfaces:

• code-only public pairing prompt;
• redacted bridge owner diagnostics;
• support-control Matt-style reconcile dry-run/apply path;
• Workbench/mac-control-doctor stale UI failure mode;
• final signed installed-app visible-agent Mac-control proof.

Do not start broad bridge module migration, repo co-location, or legacy bridge deprecation until the contract is stable and mac-control-doctor has passed against the signed installed app. Migration readiness is defined by contract stability plus proof, not by source proximity.

[100yenadmin]

Status after release-planning cleanup: keep open as the canonical post-release bridge modularization issue. Duplicate #443 is closed against this issue.

Planning packet: #480 (comment)

Boundary: this status does not claim public/customer release readiness.