AI Vault: session-list validation should tolerate agents unknown to the client #12958

Problem

src/main/ai-vault/session-list-result-validation.ts validates each session row from a remote host against z.enum(AI_VAULT_AGENTS). When the remote Orca is newer than the client and publishes sessions for an agent the client does not know yet, the degradation is not additive:

• Dropped rows push a synthetic scan issue hardcoded to agent: 'codex', so the client renders a user-visible "Skipped N invalid Agent Session History result entries." notice — misattributed to Codex — on every rescan.
• If every row belongs to unknown agents (a host used only with one new agent), parseAiVaultListResult throws: the client shows zero sessions locally, and over SSH the throw is swallowed into the relay error path and falls through to the full SFTP crawl, turning one relay RPC into a 16-root remote directory walk per scan.

This property predates any particular agent — it applies to every AI_VAULT_AGENTS addition (kimi, droid, prime-agent, …) in a mixed-version pair, which docs/reference/remote-wire-compatibility.md treats as the normal state.

Proposal

Make the reader tolerant of unknown agent values instead of enum-rejecting whole rows:

• Accept any non-empty agent string at the validation boundary and let the client drop or bucket rows it cannot render, without the misattributed codex issue row.
• Keep the all-rows-invalid throw for genuinely malformed payloads, but not for the "all rows are from a newer agent" case, so the SSH path does not regress into the SFTP crawl.
• Cover the mixed-version pair in tests per the remote-wire-compatibility guidance (old reader × new publisher).

Context

Raised during review of #12935: #12935 (comment). Not specific to that PR — filed separately because it is a shared-validation change.