[P2] Select Workbench App sessions from that server's eligible projections, not the build's global target list

[ScriptedAlchemy]

Concrete problem

At main 14c9822bc6c01d8ff2788454d0e1dc7861bc3816, AppRouteWorkspace builds its Target selector from every key in epoch.targetDigests and defaults to portable when present. That says which projections exist somewhere in the application, not which projection actually launches the selected App's server. A composite can contain portable content while this server is Claude-only; the normal first App preview then requests an ineligible portable session.

This is a source-derived selection defect; this audit did not launch the browser fixture. It is distinct from the delivered production web-ownership fixes in #628 and does not justify reopening that PR.

Source evidence

• app-route-workspace.tsx: preferredTarget, global targetDigests, and controller.open({ epochId, serverName, target }).
• application-tree.ts: leaves/server groups do not carry projection eligibility, and inspected servers are merged by name.
• web-host-launch-selection.ts already resolves declared launch candidates, compares normalized identities, and refuses genuinely ambiguous implicit selection before spawning anything.

Simplification

Give the App workspace a framework-resolved launch selection from the existing canonical build/launch machinery. Do not teach the UI a second artifact parser, host default list, or candidate-spawn probe. Where richer projection information must cross the Workbench boundary, extend the existing contracts rather than inventing a parallel application graph.

Acceptance

• Portable content + a Claude-only generated App server opens the valid server projection by default.
• The selector offers only projections that can actually launch this server and serve this App; unselected/unsupported entries are not plausible choices.
• Equivalent launches can use one deterministic representative. Materially different launches require an explicit choice, with an intelligible explanation.
• Browser presentation profile remains independent of server launch projection. Choosing a Codex-like frame is not permission to select an unrelated Codex artifact.
• A rebuild that changes server eligibility retires the old session and revalidates selection; late results cannot repopulate the new selection.
• Preserve canonical server/App IDs and existing explicit requested-target refusal; never silently fall back from an invalid explicit choice.
• Test reversed target order, a server missing from portable, two eligible unequal launches, and removal of the selected launch during rebuild through the real workspace/session boundary.

No process is started merely to see which candidate works. No new host requirement, portable requirement, duplicated transport, automatic tool approval or changes to domain code.