Register push only for the signed-in account's Burrows

[nedtwigg]

Hardening for Pocket's push registration across an account switch.

Pinned Burrow records outlive a sign-out, so after signing in to a different account the Burrows list can still show a record paired under the earlier one (it keeps its offline row, per docs/specs/pocket-app.md). Enable treated that row as a push target and asked this session's Relay to register it. The Relay scopes registration to the session's account and refuses it, and that refusal stopped the loop before the current account's own Burrows registered, leaving the offer card up for an Enable that could never finish.

• loadBurrows in lib/src/remote/pocket-app/App.tsx marks a record whose accountId is not the signed-in account's as otherAccount on its BurrowView, from the same account read that already decides removed.
• isPushTarget excludes it, so Enable never sends it to the Relay and the push offer does not count it.
• The row itself is unchanged: it stays listed with its offline face, and nothing about its record is touched.

Tests

lib/src/remote/pocket-app/App.push.test.tsx → "skips a Burrow paired under another account, and keeps its row": with the first record under an earlier account (and a Relay that refuses it), Enable registers only the second, reports no error, and the offer goes away. It goes red with the isPushTarget change reverted.

Specs

• docs/specs/pocket-app.md → "Detecting install state, and what cannot be detected" (the push-registration rules): Enable registers, and the offer counts, only the signed-in account's paired Burrows its list still names (word budget ratcheted).

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	3a32427
Status:	✅  Deploy successful!
Preview URL:	https://77d06702.mouseterm.pages.dev
Branch Preview URL:	https://pocket-account-burrow-filter.mouseterm.pages.dev

View logs

[dormouse-bot]

The change itself looks right to me, and I have no findings on the diff. I'm holding the approval only because Workflow Lint is red on this head. It isn't caused by this PR: zizmor flags ci.yml:403 ("action's hash pin has mismatched or missing version comment"), which this PR doesn't touch, and main fails the same way in run 39445113310. Once main is fixed and this PR's checks are green, this is ready to approve.