chromeStorageImportData.ts is dead code: no production caller, and it owns only 1 of the import buffer's 5 keys

[Cyclodex]

packages/shared/chromeStorageImportData.ts has no production caller. Its only references anywhere in the repo are the barrel re-export (packages/shared/index.ts:2,10) and its own test file. Noticed while correcting the storage writer table for #100.

Why it is dead

The side panel reads and writes the same "importData" key directly through the generic primitives, bypassing the module entirely:

// ImportEntries.tsx:104
chromeStorage.save(data, "importData");
// ImportEntries.tsx:233
chromeStorage.load<ImportRow[]>("importData").then((data) => { … });

So the module is not "not yet wired up" — there is a second, live implementation of the same thing sitting next to it.

Why it cannot simply be wired up as-is

It only knows about "importData", but the import buffer is five keys — importData, importHeader, importFooter, importTemplates, entryStatus — which #87 established have to be written together, because the latter two are keyed by row/column index into the first. Its own TODO says as much:

// TODO: They are still unused, and need to get header and footer handlers as well.

Adopting it today would therefore reintroduce exactly the inconsistency #87 fixed, unless it is extended to own all five.

Also note deleteImportData was the "loaded gun" in #89: it called remove(id, "importData"), which wrote the result back to "entries" and would have destroyed the user's templates. That is fixed now, but the function remains a documented no-op (docs/architecture/storage.md, known issue 3) that nothing calls — a no-op that is only harmless because it is unreachable.

Suggested fix — pick one

a) Delete it. Remove the module, its barrel entry and its test. Git history preserves it, and ImportEntries.tsx already does the job. Smallest diff; the module has never been used in production.

b) Make it the real owner of the import buffer. Extend it to all five keys with a single atomic read/write, then have ImportEntries.tsx go through it instead of raw chromeStorage.save/load. This is the "longer term" direction #87 recorded — storing the whole import under one key written atomically — and it would give the buffer the same shape chromeStorageTemplateEntries gives templates. Bigger, and it needs a migration for buffers already in users' browsers.

Either way, docs/architecture/storage.md needs its "Owner module" column and known issue 3 updated, and option (b) supersedes the known issue #87 left behind.

Leaving it as-is is the option worth avoiding: a shared module that looks like the API for a feature but is bypassed by that feature is exactly the sort of thing the next person wires up without noticing it only covers a fifth of the state.