[Bug]: Guard orphaned Goal state before guided bootstrap or host activation

[hua03]

Summary

start-goal --guided can classify a project as registry_without_goal even when an active-state file for the requested Goal id still exists in a legacy or alternate state location. The packet then proceeds with the normal connect_if_needed bootstrap and identity-onboarding route. This makes an operator-initiated reset ambiguous: an orphaned state is neither a connected Goal nor a clearly failed deletion, yet a later host session can create a new lane and Todo projection under the same Goal id.

This is separate from #4800. That issue proposes host-neutral paths and an explicit migration. This issue asks for a safety fence whenever registry and state artifacts disagree, including during the transition period.

Observed behavior

A Pi session trace on LoopX 1.0.5 showed this sequence:

1. The project registry existed but had no entry for the requested Goal id.
2. An active-state file for the same id still existed in the legacy state location.
3. start-goal --guided reported goal_found: false, state_file_exists: true, and connection_state: "registry_without_goal".
4. The returned guided transaction still exposed connect_if_needed (bootstrap) and fresh-agent registration commands. In this case the generated registration command also retained the legacy global runtime path.
5. A subsequently started Pi session received the normal guided packet and created a fresh agent lane, Todos, and state writebacks for the same id. Later diagnose reported healthy state, so the discontinuity was not surfaced.

The Pi extension itself does not autonomously call its startLoopx helper: that helper is reached from the /loopx command handler. Its session JSONL records the resulting synthetic guided packet, but not the slash-command invocation or source, which made attribution difficult. Regardless of the source of that command, the CLI packet should not treat an orphaned active-state candidate as ordinary absence.

Expected behavior

When no matching registry Goal exists but one or more state candidates exist for the requested id:

• Return a distinct, blocking connection state such as orphaned_goal_state; do not return a bootstrap, agent-registration, Todo, quota, or host-activation continuation.
• Identify candidates using both the current and configured legacy state locations, without silently merging or copying them.
• Provide a preview-only, explicit resolution route: inspect, back up, then choose one of archive/delete/migrate/adopt. Any destructive action must require explicit confirmation.
• Once a Goal is deleted, archived, or migrated, revoke the former Goal instance for host bindings. A newly bootstrapped Goal with the same human-readable id must have a new opaque instance/generation id; guided packets, bindings, and quota calls should validate that instance id.
• Surface the mismatch in diagnose until it is resolved.

Reproduction shape

1. Create a valid project registry with no Goal entry named sample-goal.
2. Leave an ACTIVE_GOAL_STATE.md for sample-goal in a legacy or alternate project state directory.
3. Run:

loopx --format json start-goal --guided --project . \
  --goal-id sample-goal --host-surface pi --goal-text "sample"

4. Observe registry_without_goal together with state_file_exists: true and a bootstrap-oriented continuation.

Acceptance criteria

• A regression test covers the registry-missing-goal + extant-state-file case.
• Guided output is non-mutating and has no activation path in that state.
• Resolution commands are explicit, previewable, backed up, and leave exactly one writable authority.
• Host bindings cannot continue or attach across a Goal deletion/rebootstrap merely because the Goal id is reused.
• diagnose flags unresolved orphan state instead of returning a clean result.

No repository paths, user data, credentials, or raw session logs are required to reproduce this behavior.

[hahahahahayesyeseys]

Claiming the fence half of this: distinguishing registry_without_goal from an orphaned state candidate, and making the guided packet carry no bootstrap / agent-registration / Todo / quota / host-activation continuation in that state.

One finding from implementing it, because it narrows what "previewable resolution route" can mean today. I ran the shipped commands against a synthetic project that reproduces your sequence (registry with no entry for the id, project-local active-state file present):

• uninstall-project --goal-id <id> --archive-state returns goal id not found in project registry. It selects goals from the registry, so it cannot reach a Goal the registry no longer declares.
• archive-runtime --goal-id <id> resolves only under the shared runtime root (<runtime-root>/goals/<id>), not the project-local route where this orphan lives.
• backup-state --project . --current-project-only works and stays a dry run until --execute, so the inspect-and-back-up half of your route exists; the archive/delete/adopt half has no owning command yet.

So my slice reports the orphaned candidate routes, blocks every mutation continuation, and states explicitly in the gate that archiving or adopting project-local orphan state has no shipped command. That leaves two of your acceptance bullets as follow-ups that need an owner decision on the command shape: a previewable project-local state archive/adopt route, and the opaque Goal instance/generation id for host bindings.

I will not touch the default-path work in #4800.

[hahahahahayesyeseys]

Fence slice opened as #4808 (Refs this issue): the orphaned-state distinction, the blocking guided transaction and command pack, and the coverage including the shipped onboarding qualifier reporting route=stop. The three acceptance bullets left open -- diagnose surfacing, a previewable project-local archive/adopt route, and Goal instance/generation identity -- are itemized in that PR's scope section.