test(store): a bundle import never lets a stale bare-account record hide a strand (T13378)

[kryptobaseddev]

Summary

This is a regression test only, with no runtime change. review-hotfix (on #1982) suggested that a portable bundle import could keep a stale _exodus_recovery_bare_accounts record, which would then vouch for a stranded bare row and let sync enable. I probed it, and the premise is false:

• legacyStrands re-checks each record's row count and key digest against the bare table on every call (isAccounted), and setSyncFlag runs it before enabling. A stale record never suppresses a strand.
• Bundle import places each project cleo.db whole, from one VACUUM INTO snapshot. Its bare tables and its record always come from the same moment. Vault restore differs: its bare tables are local-only and carried in from this machine, which is why settleRestoredBareAccounts (fix(vault): a restore settles the reconcile record against the restored bare tables (T13324) #1982) lives there. That settle keeps a matching record; it isn't a guard against suppression.

The new test in portable-bundle.test.ts does the following:

• writes a store whose record went stale (its bare task_labels gained a row after the record was written);
• exports and imports it;
• asserts legacyStrands reports task_labels (missing 2) and setSyncFlag(…, true) throws LegacyOnlyStoreError.

It doesn't depend on #1982, so it's based on main.

T13378's runtime ACs were dropped with this evidence (team-lead option 1), and the evidence is noted on T13324.

Verification

• portable-bundle.test.ts passes (10).
• Mutation: an isAccounted that trusts any record fails the new test.
• biome, pnpm run typecheck (tsc -b), build, gate 39 and skill coverage --base origin/main all pass.

Closes T13378.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VjjTKbQXyCFdkLBSeuyKLt