Chunk compaction: fold the holes card deletes leave

[jvsena42]

Closes #51.

The problem

Cards are assigned to chunks by sequential append, and deleteCard shrinks that chunk's count rather than resequencing every later card — closing the hole in place would rewrite every following chunk, which is the write amplification the layout exists to remove.

Holes never cost correctness. They cost density: a deck that imported 20k and deleted 15k opens with the request count of a 20k-card deck.

What this does

DeckRepository.compactDeck folds one pair of neighbouring chunks at a time until no two fit in a record — which is the record count the cards actually need. Ordering survives because the pair is renumbered inside the landing chunk's own slice of the ord line, so no chunk outside the pair moves.

The issue floated three options; this is #1 and #3 together, and #1 turned out to need a fix of its own (see below).

Three things it deliberately does not do:

• It never runs inline. deleteCard and listOwned only ask for a pass, through a new BackgroundTasks.scheduleDeckCompaction (WorkManager / BGTaskScheduler, same shape as the media re-host sweep). Compacting on the delete path would cost a merge per card in a bulk delete and rewrite records followers have cached, mid-edit.
• It does not bump updated_at or emit changes — nothing user-visible moved, so lighting up every follower's "the author published" badge would be a lie. The per-chunk stamps do move, which is what makes a follower re-fetch the folded pair.
• It does not go through writeChunksAndManifestLocked. A merge removes a record, so it writes the landing record, then the manifest, then empties the source; emptying first would leave a window where the manifest points at a chunk that 404s.

It converges — every merge strictly shrinks the table — and it is budgeted (DEFAULT_COMPACTION_MERGE_BUDGET) and resumable with no cursor, since each pass re-derives the next merge from the manifest.

The consequence worth knowing about

A merge drops the pair's higher n, so the chunk table is no longer contiguous. Nothing downstream assumed it was — except publish, which cleared stale records over batches.size until previous.chunks.size, a count. On a compacted deck that clears a record that no longer exists and orphans the one that does. It now deletes by chunk number.

Also here

• fix(import): give the paste field a fixed height — found while testing. The field was heightIn(min = 160.dp), so it grew with whatever was pasted; a 102-line list pushed Next off the bottom of the screen and under the keyboard, making the paste flow unusable for exactly the deck sizes it exists for.
• docs(journeys): the scripted sign-in failure is pacing, not repetition — driving sign-in here produced a clean discriminator for something RESULTS.md had recorded as unexplained. ~15s from beginSignIn to Authorize (a layout dump between each tap) fails with "the relay isn't responding"; the same three taps chained at ~3s pass first try. That accounts for the "manual sign-ins succeed where scripted ones don't" note — a human taps through in a couple of seconds, a journey runner that verifies each step does not. Journey 01 now spells out the chain and moves every verification after it.
• The two iOS BGTask handlers were the same twenty lines twice and now share one, which also fixes a swallowed cancellation: the expiration handler cancels the job, and a plain runCatching went on to reschedule and report success — both of which the handler had already done.

Verification

./gradlew :shared:allTests detektAll :composeApp:assembleDebug green; iOS compileKotlinIosSimulatorArm64 green.

23 new tests — the chunk-table maths, and the repository pass over a FakePubkyClient: keeps every card and its study order, stops at the record count the cards need, writes the landing record before dropping the source, leaves the table untouched when a chunk is unreadable, repairs an entry counting cards its record no longer has, and the gapped-numbering case a republish used to orphan.

Driven on the Pixel_9 emulator against a real homeserver, which is the part that matters:

step	result
publish 102 cards	2 chunks, [100, 2] — no compaction asked for
delete 1 card	[99, 2] = 101, still won't fit — nothing scheduled
delete 1 more	[98, 2] = 100 → BgTasks: scheduleDeckCompaction: enqueued (unique, KEEP)
worker runs	DeckCompact: compact: ggtiq9gttbk8 merges=1 cards=2 2→1 chunks
reopen the deck	100 cards, in order from word3 (the two deleted were word1/word2)
list decks again	no further compaction signal — converged

🤖 Generated with Claude Code