Completes the userId cleanup Phase 2c left half-done. The creating-hook
(commit e9b9544ea) stopped stamping userId on new writes, but existing
rows still carried the column from v28 onwards — mixed state. This
migration removes the column from every data-record row and drops the
articles module's userId indexes that are now dead.
v35.stores():
Re-declares articles / articleHighlights / articleTags without
the `userId` index. Other indexes (status, savedAt, isFavorite,
siteName, originalUrl, [articleId+startOffset], [articleId+tagId])
stay identical.
v35.upgrade():
Iterates every SYNC_APP_MAP table that isn't on the USER_LEVEL list,
calls `.modify()` to `delete record.userId` on every row. User-level
tables (userSettings, userContext, newsPreferences, meditate/sleep/
mood/time/invoice/broadcast/wetterSettings, userTagPresets) keep
their userId — their ownership model is user-scoped by design.
The USER_LEVEL set is duplicated inside the upgrade closure because
the hook-registration loop (where the runtime USER_LEVEL_TABLES const
lives) hasn't run yet when the upgrade fires — Dexie applies upgrades
before we call `db.table(...).hook()`.
Public-type converters (tags-local's toTag/toTagGroup, calc's
toCalculation/toSavedFormula) already fall back to 'guest' / '' when
userId is absent, so the field's disappearance doesn't break
downstream reads.
After this ships, the "no table has both userId AND spaceId"
invariant from the plan is truly met on data records. User-level
tables still have both (v28 stamped spaceId onto them) but that's a
separate, lower-priority cleanup.
Type-check clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
f4c66241ca