Fix F5 debug profile and blocked-page state

[danielchalmers]

Summary

• route blocked-page state lookups through canonical block ids so extension pages do not depend on unreliable sender tab context
• re-evaluate block-id state against fresh rules so disabled groups no longer leave stale blocked-page details active
• make the VS Code F5 profile launch cleanly by removing stale Chrome session/cache state and clearing the debug profile crash marker while preserving extension settings

Root Cause

F5 was loading the latest built extension, but the persistent Chrome debug profile restored stale blocked-page tabs and kept Chrome's crashed-session marker. Those restored pages still had the old ?url= blocked-page URL, which made the debug session look like it was running old code and showed Block details unavailable. Separately, extension-page runtime messages needed to resolve state by blockId because sender.tab is not reliable from the blocked page.

Validation

• npm run typecheck
• npm run typecheck:test
• npm run build:dev
• npm run lint
• npm exec prettier -- --check .vscode/launch.json .vscode/tasks.json
• npm exec playwright -- test test/e2e/blocked.spec.ts
• Verified with Computer Use in the actual VS Code/Chrome F5 flow: after stopping the prior debug session and pressing F5, Chrome opened one clean about:blank tab with no restore prompt; navigating to https://www.google.com/search?q=asdf blocked with ?blockId=... and rendered the responsible filter details.

Closes #104

[danielchalmers]

This is a complex and messy solution that is not actually passing tests either. Need more planning in #104.