Persistent interactive checkboxes keyed by document hash

[SyNeto]

Goal

Make GFM task-list checkboxes (- [ ] / - [x]) clickable in the rendered view, and persist clicks across page reloads using chrome.storage.local, keyed by a hash of the document.

Why

Reading checklists in long Markdown docs (TODO lists, install runbooks, exam prep) is far more useful when items can be ticked off and the state survives a reload. Today marked emits <input type=\"checkbox\" disabled>, so there's no interaction at all.

Proposed approach

• Override the marked task-list renderer (or post-process the DOM) to drop the `disabled` attribute and attach a click handler.
• Hash the document content with `crypto.subtle.digest("SHA-256", ...)` and use that as the storage key.
• Add `"storage"` to the `permissions` array in `manifest.json`.
• On render: read existing state for the doc hash, apply check marks. On click: write back.

Open questions (must be resolved before implementing)

• Hash input. Content-only is stable across path changes but resets on any edit. URL-only is unstable. A hybrid (content hash + URL fingerprint) might be best.
• Per-checkbox sub-key. Indexing by position is fragile (inserting a box above shifts all indices). Hashing the surrounding text is more robust but more complex. Need a decision.
• Eviction policy. `chrome.storage.local` has ~10MB quota. With many visited docs, when do we drop old entries?

Note (context loss)

We had a detailed hashing strategy worked out in a previous session that wasn't saved before a misfired `rm`. The high-level intent above survives in the README; the specifics (exact hash inputs, sub-keying, edit-invalidation policy) need to be either re-derived or recovered from any local notes before coding.

Constraints

• No CDN dependencies. Web Crypto API for hashing is already built into the browser; no library required.

Acceptance criteria

• Checkboxes are interactive in rendered view
• Clicking a checkbox persists across reloads of the same document
• State doesn't bleed between unrelated documents
• Edits to a document invalidate stale state in a documented, sensible way
• No additional runtime dependencies; no network requests