PRD: Clear desktop-unavailable startup state in browser fallback

[Hector-Ha]

Problem Statement

When InstantRepo is opened in a plain browser during Wails dev QA, the app correctly reports that desktop controls are unavailable, but Recent Events still contains the startup message saying desktop controls are live. This contradicts the status banner and makes QA results harder to trust.

Solution

Startup state should be derived from desktop bridge availability. If the Wails bridge is missing, the first activity should clearly say browser fallback is active and should reuse the same desktop-unavailable guidance shown in the banner. If the bridge is present, keep the normal ready message.

User Stories

1. As a QA tester, I want the startup status and Recent Events to agree, so that I know whether Chrome/browser testing can drive desktop actions.
2. As a desktop user, I want the normal ready message when the Wails bridge exists, so that the desktop window still feels ready for setup work.
3. As a browser fallback user, I want clear unavailable guidance before clicking clone/analyze, so that failed actions are not misread as repo-analysis bugs.

Implementation Decisions

• Add a small desktop-session availability check around the existing Wails bridge detection.
• Build the startup activity from that availability check instead of hard-coding “desktop controls are live”.
• Keep desktop API call behavior fail-closed when the bridge is absent.
• Do not add browser-side backend access in this slice; this only fixes contradictory messaging.

Testing Decisions

• Test the public desktop API/session helper behavior with and without a bridge source.
• Test the startup activity builder for both bridge-present and bridge-missing states.
• Keep tests behavior-focused and avoid rendering implementation details.

Out of Scope

• Making Wails desktop actions executable from a normal Chrome tab.
• Changing clone/analyze backend behavior.
• Closing this issue after implementation.

Further Notes

Found during manual QA against http://127.0.0.1:34116/ in Chrome. The page banner said desktop controls were unavailable while Recent Events still showed “Ready: Desktop controls are live.”

[Hector-Ha]

Triage Update

This PRD has a concrete implementation slice in #29 and is ready for agent work. Moving parent PRD to ready-for-agent with category bug.

[Hector-Ha]

Closing as not planned, not resolved.

This issue came from the earlier idea of using a plain browser app as a QA/product surface. Current scope changed: InstantRepo remains a desktop app, Chrome is only a private/local QA control surface through .qa-local, and public work should expose production-safe CLI/bridge contract surfaces only.

The still-valid part is covered by #40: bridge contract metadata and a clear unavailable/outdated state when the frontend cannot talk to the expected desktop/private shim bridge. This issue should not be picked up as a standalone browser-app bug.