test(cli): pin the multi-installation projection precedence (TASK-019)

[lilyshen0722]

Closes the test half of TASK-019 — "daemon multi-installation projection: test inaccessible peer runtime precedence".

What the projection is

A runtime token carries an identity, and one identity can hold several active installations. bootstrapAgentRecordFromEnv (cli/src/commands/agent.js:117) collapses that list into one local record, and the collapse is positional:

first {type:'installation', status:'active'}  →  else installations[0]  →  else null

Only the first link had a test (the existing "synthesizes a full record" case, where an agent-admin DM row sits ahead of the installation). This pins the rest:

• first-among-several is positional. Two active installations → the first wins. Nothing in the payload orders them (the server's rows come from an un-sorted AgentInstallation.find), so which pod a multi-installation seat projects is currently insertion order. Pinned so a change to that preference has to be deliberate.
• no installation rows → the first DM row becomes the pod. Reachable: the endpoint appends DM rows after installations and never invents an installation row.
• empty / missing / non-array list → podId: null, instanceId from the identity.
• identity.instanceId outranks the chosen row's, which only supplies a fallback.

Mutation proof

The status === 'active' term is load-bearing and I proved it rather than assuming it. Dropping it from the find predicate:

✕ projection: an installation that is not active is skipped in favour of one that is
Tests: 1 failed, 35 passed, 36 total

Exactly one test reds — the case built for it (an active DM row, an inactive installation, then an active installation: with the term the third wins, without it the second does).

Measured while writing this, and it changes what a reader should worry about

The status term never rejects anything the live endpoint serves: both auth paths query status: 'active' (backend/middleware/agentRuntimeAuth.ts:121 for a User-row token, :186 for an installation-bound token), and agentsRuntime.ts:440 maps status: inst?.status || 'active'. So the only reachable fallback is "no installation rows at all", not "a stale row". The inactive-row case is still pinned, labelled as unreachable today, because if that endpoint ever widens the failure is silent: a seat booting against a pod whose installation is not live.

I checked the producer before writing the risk down. A first draft of this asserted the CLI could project an inactive installation row from the live endpoint; reading agentRuntimeAuth showed that is not reachable, so the test now says so instead of implying a defect.

Verification

• cd cli && npm test — 39 suites / 543 passed / 10 skipped, green (the six new cases included).
• npm run lint:cli — clean.
• Tests only, cli/__tests__/attach.test.mjs (+89), a single commit 910b2f9a on main. No version bump: .github/workflows/package-version-guard.yml checks $pkg/src only, so a test-only diff needs none.
• De-stacked before merge (Vera caught it): the branch had been cut from the rule-26 checklist branch, so it carried docs(review-checklist): rule 26 — a derived default must be one its consumer accepts #1755's 5c367a1a as a second commit — two files, and a merge-order coupling to an unrelated docs PR. Rebased --onto main in place; the cli/ diff is byte-identical (diff of the pre- and post-rebase patches is empty), so the cleared content is unchanged and this PR is now the one file its title claims. Whichever of docs(review-checklist): rule 26 — a derived default must be one its consumer accepts #1755 / test(cli): pin the multi-installation projection precedence (TASK-019) #1756 lands second is no longer anything at all. The head therefore moved 4ad2e753 → 910b2f9a after Vera cleared it: same patch, different parent, called out here rather than silently.
• Not covered, and named because the row's title was ambiguous: the other runtime-type precedence in this file — the inst.config?.runtime?.runtimeType || inst.runtimeType || '?' chain in the admin installations listing (agent.js:2663) — has no seam to test through, so pinning it means extracting the row formatter first. I asked @vera which surface TASK-019 meant. Her answer: she cannot retrieve 66201 and will not reconstruct it, so the row is decided on the code — the daemon projection has a real, testable precedence and this PR pins it; the admin listing is a display fallback with no seam. The row now records the original wording as unrecoverable.