Maple Work: complete macOS filename rollout around 0.1.0 with legacy update compatibility #1244

Follow up around 0.1.0, after the next few weeks of invited beta. Preparatory PRs: #1234 (Maple Work display branding) and #1242 (macOS updater accepts both known bundle names). This issue does not request a release or make the filename change a beta blocker.

The bridge allows Maple Agent.app and Maple Work.app, preserves the existing installed path, and retains the old staging/receipt and install-lock contracts. Shipping it early puts compatibility in new beta installations. It does not automatically rename installed applications, and elapsed time does not guarantee every older client has received it: a 0.0.5 client can skip directly to a later latest release.

Preferred rollout

• Make fresh macOS downloads install as Maple Work.app when the coordinated packaging work is ready.
• Keep the existing macOS feed's updater archive rooted at Maple Agent.app. Older clients require that root; bridged clients installed under either name can consume it. Retain a legacy-root upgrade path rather than relying on a bridge-only intermediate release or an assumed adoption percentage.
• Existing installations may keep their physical Maple Agent.app path and show Maple Work. Automatically moving them is optional separate migration work, not required to complete the public rename.
• Keep bundle ID, Team ID, executable/CLI, profile/data/settings locations, keys, wire formats, existing update/download URLs and Linux installation identity stable.

Remaining work and acceptance

• Coordinate macOS package generation, localized bundle-name metadata, DMG/archive roots and downloaded-package verification. Preserve the current signed-content/provenance guarantees; explicitly account for any deliberate packaging differences rather than simply disabling payload comparisons.
• Review the publisher's legacy Maple Agent.app/Contents/Info.plist lookup alongside packaging. The existing feed must remain consumable by pre-bridge clients.
• Validate a real signed pre-bridge 0.0.5 installation updating directly to the new release through the existing feed, including relaunch, login/settings persistence and normal Quit/cold reopen.
• Validate a fresh Maple Work.app installation and its next signed in-app update using the retained legacy-root archive. Verify display branding, preserved installed path, native signing/notarization and receipt/backup cleanup.
• Preserve the other installation if both names exist in the same directory, maintain shared locking and reject unsupported/mixed/unsafe archive roots.
• If automatic installed-path renaming is later desired, design collision, interruption, launch registration, relaunch and failure recovery explicitly before implementing it. Do not silently remove a sibling installation.

Research's updater, publisher and installed-client compatibility remain outside this issue. No new feed, bucket, Worker or signing key is required by the preferred rollout.

Related branding cleanup

Existing Linux users retain the old external desktop-launcher label after an in-app bundle update; fresh installations already say Maple Work. Refresh only an unchanged, installer-receipt-owned regular desktop entry, preserving ownership/symlink checks and user customizations and updating its receipt consistently. Keep the Linux bundle and CLI names stable. Rerunning the first-install script is not an upgrade path because it intentionally refuses existing integration files. This cosmetic cleanup does not block the current updater or preview.