contracts: model companion adapters explicitly in the manifest/build plan

[doodlewind]

Registered from #293 review rounds 2–3: the note's svc companion adapter is selected by manifest.name === "pocket-note" in tools/macos.ts and by the host --editor flag, not by anything the manifest/plan declares. The capability system deliberately does NOT cover companions (pointer/text/IME/clipboard on the macOS targets are companion-delivered), so the adapter needs its own first-class spelling:

• a manifest field declaring the companion service name(s) an app speaks (the svcOpen names — today's svcOpen("note"), the stage packages' authored allowlists),
• the resolved plan carrying it so hosts derive their svc allowlist + adapter wiring from the plan instead of app-name conventions,
• admission/diagnostics for "companion required but host serves none".

svcOpen is deny-by-default as of #293, so the failure mode is truthful degradation (apps run standalone) rather than misreporting — this issue is about removing the name convention, not a correctness hole.

[doodlewind]

Two more items that belong to this debt, from #293 review round 5:

• The resolved plan is not yet the complete host boot truth: tools/macos.ts re-reads the raw manifest for the fixed/dynamic viewport policy because ResolvedBuildPlanContent (framework/src/manifest/plan.ts) does not carry it. Companion metadata and the viewport policy should land in the plan together so hosts derive everything from one artifact.
• The Apple sidecar shares the svc queue without an allowlist entry point: engine/apple embeds the same UiSurface but its C ABI exposes no set_svc_allowlist. Post deny-by-default (feat(gpui): gpui render backend and the macos-app target with native text layout #293 round 4) its guests' svcOpen always answers false — not a regression (the demo never calls svcOpen), but when the Apple host grows a companion it needs the declaration surface too.