Fix plan

Re-key durable state by sha1. Treat filekey as a per-session lookup token only.

Schema migration

Today's metadata-page shape:

{
  hiddenFilekeys: string[],
  filenames:      { [filekey]: string },
  drafts:         { [sha1|filekey]: {...} },
  history:        { lastSyncedAt, items[] }
}

Target shape:

{
  hiddenSha1s:    string[],            // canonical
  filenames:      { [sha1]: string },  // sha1-keyed
  drafts:         { [sha1]: {...} },   // sha1-only
  history:        { lastSyncedAt, items[] }
}

One-shot migration in loadOne('metadata'), after the page is parsed:

1. If parsed.history.sha1Index is present (legacy from the previous fix), drop it. (Already shipped in commit c0b736e; this is a reminder so the migrations don't fight.)
2. If parsed.hiddenFilekeys exists and parsed.hiddenSha1s does not: do not silently drop. Defer migration until after the first stash fetch lands — at that point we have {filekey -> sha1} for live stash rows, and we can translate hidden filekeys to sha1 for the entries that are still around. Anything we cannot translate (because the stash entry expired) is logged and dropped — same risk as today, no worse.
3. If parsed.filenames is filekey-keyed (heuristic: keys match filekey pattern), do the same join via current stash to convert to sha1-keyed.
4. scheduleSave('metadata') writes the cleaned-up shape. Same debounce + auto-shrink mechanism as the sha1Index cleanup.

Code changes (high level)

1. src/api/user-store.js — add sha1-keyed analogues of the existing filekey functions: hideSha1, unhideSha1, getHiddenSha1s, pruneHiddenSha1s. Switch setStashedFilename / getStashedFilename to take sha1 as primary; accept filekey as a transitional fallback. Add the migration helper described above.
2. src/app.jsx — onDelete, onBulkDiscard, the visibility filter, and the duplicate-in-stash result-map keying all switch to item.sha1. When a row hasn't yet acquired a sha1 (the backfill effect from commit bd83df4 hasn't run), the row is shown as ungroupable / non-discardable for that brief moment.
3. src/api/normalize.js — set id = sha1 for stash rows once sha1 is known; while sha1 is missing, keep the filekey-based id but mark the row as "pending-identity" so consumers can degrade gracefully.
4. src/main.jsx — pruneHiddenFilekeys becomes pruneHiddenSha1s(stashRaw.map(i => i.sha1).filter(Boolean)). Items without sha1 do not contribute to the prune set.
5. Drag-drop (src/ui/dropzone.jsx) — sha1 is already computable client-side from the file bytes (the in-stash duplicate detection from commit 939cfe4 relies on it). Promote that compute to happen before the optimistic row is added, so new rows have stable identity from the start.

Risks and open questions

• Items without sha1. mystashedfiles does not always return sha1; a stashimageinfo fetch is required. Backfill exists (commit bd83df4). During the gap a row has no canonical identity. Decide during implementation: render greyed-out, render with filekey-only fallback (legacy behaviour), or block the row from being soft-deleted until sha1 lands.
• sha1 collisions across user accounts. sha1 is content-defined, so two users uploading the same bytes share a sha1. That's already fine — our state is per-user (per User:<self>/UploadWorkbench/Metadata.json), so no cross-contamination.
• Migration write spike. First load after the fix triggers one extra metadata-page edit per existing user with legacy state. Same shape of impact as the sha1Index cleanup; small text size, well within wiki edit budget.
• Re-upload of expired-then-recreated stash. If the user soft-deleted file X, X expired, and they re-uploaded the same bytes a week later — should the new entry inherit the soft-delete state? With sha1 keying, yes. That's a behaviour change worth calling out in the CHANGELOG. (We think it's the right behaviour: "soft-delete by content" rather than "soft-delete by stash ticket".)

Versioning

MINOR bump — visible behaviour fix + metadata schema migration, no breaking external API. Target: 0.2.x → 0.3.0.

Verification (when implementing)

1. Soft-delete a file, force-reload, confirm it stays hidden.
2. Soft-delete a file, wait until MediaWiki re-issues its filekey (or simulate via API by deleting and re-stashing same bytes). Confirm soft-delete is preserved.
3. Open a session with a legacy Metadata.json (hiddenFilekeys only). Reload. Confirm the migration runs, hiddenSha1s appears, the page shrinks, and visible behaviour matches the legacy state for files still present.
4. In-stash duplicate detection: two rows with the same bytes, soft-delete one. Confirm the visible row is no longer flagged as a duplicate (because the only twin is hidden).