feat(launch): derive host-authoritative launch targets from pinned kits #577

Outcome

Define and implement a host-authoritative launch-target registry derived from
validated, pinned kit metadata. ACQ resolves a user-facing target such as
opencode, paseo, goose, or shell to an explicit launch contract.
Backends consume that contract; they do not infer it from a filesystem wrapper
or install an adapter-native agent.

This issue owns the launch-target contract for both current hybrid kits and any
future OCI kit v3 adoption. It is a prerequisite of, and is consumed by,
GSA-TTS/agentic-coding-quickstart#628.
That epic owns the OCI migration/evaluation; this issue does not select OCI
artifact, lifecycle, CA-trust, or composition semantics.

OpenShell remains a backend consumer of this contract. It must not define a
parallel OpenShell-only agent/entrypoint model.

Target kinds

A service target must not claim an interactive TUI merely because it installs a
CLI. Conversely, an interactive target must not be substituted by a service
wrapper that overwrites the CLI's launcher path. This resolves the current bad
pattern of multiple kits competing to own ~/.local/bin/opencode.

Required metadata and validation design

This issue does not declare a new schema yet. A Patterns schema/validator/
fixture increment must precede Quickstart implementation. The minimum proposed
metadata needs:

• stable target identifier, display name, and kind;
• provider kit identity and pinned provenance;
• interactive argv or service readiness/connection contract;
• declared backend support and explicit unsupported behavior;
• runtime prerequisites and ownership boundaries;
• deterministic conflict rules: one selected interactive target; service
  targets compose only when identities, ports, readiness names, and declared
  resource ownership do not conflict;
• a prohibition on launcher-path ownership as a selection mechanism.

Arguments, workspace paths, credential values, host-port allocations, and
runtime process IDs are not durable target metadata. ACQ supplies them per
invocation after target resolution.

Scope

• Generalize existing inferred built-in agent-kit selection into registry
  resolution for supported targets.
• Preserve shell as an ACQ-owned explicit no-kit target.
• Translate resolved target contracts through OpenShell, MSB, SBX, and later
  backends without backend-native agent installers.
• Preserve host-authoritative provenance, application state, reattach/start
  idempotency, and explicit unsupported-field rejection.
• Define service readiness and terminal-return behavior before adding service
  targets to acq run.
• Migrate OpenCode as the first interactive target; migrate Paseo only after its
  service contract is declared and tested.

Explicit non-goals

• Do not infer a target from arbitrary extra kits, PATH entries, or filesystem
  wrapper files.
• Do not make every installed CLI a user-facing target.
• Do not replace OCI workload entrypoint semantics with mixin entrypoints.
• Do not change the currently pinned kit schema in this issue.
• Do not add a generic background-service manager without declared readiness,
  port, lifecycle, and recovery semantics.

Cross-repository sequencing

1. Patterns: propose and validate neutral launch-target metadata plus
   success/failure fixtures.
2. Quickstart: resolve only built-in/pinned target declarations; persist selected
   target provenance; add backend translation and tests.
3. OpenShell: consume the resulting resolved contract as one backend
   implementation, rather than defining a parallel model.
4. OCI evaluation in epic(acq): evaluate adoption/extension of OCI sandbox kit spec v3 #628 consumes this contract; it does not redefine it.
5. Add service targets only after their readiness and connection behavior has a
   live verification path.

Verification

• Focused tests: inferred and explicit precedence; unknown/ambiguous target
  refusal; provenance persistence; reattach/start behavior; target-kind dispatch;
  service readiness failure; no launcher-file collision.
• Backend tests: identical resolved contract reaches MSB/SBX/OpenShell or
  explicitly fails before partial application.
• Live checks: OpenCode TTY attach; Paseo/service readiness plus terminal return;
  two distinct workspaces; restart/recovery; no host-port pinning assumption.

Human review must approve the concrete metadata schema and any behavior change