[aleskiontherun]

Each row of the logbook import report's dives now carries notes: list[int]: indexes into the same report's notes, ascending, naming the notes about that dive. It's on both POST /import/logbook/preview and POST /import/logbook, which share ImportReport. This is the contract the web half renders against. report.notes stays whole and unchanged, so every note is still listed once and notes_truncated keeps its meaning. A note the cap dropped is on no row. No note is on two rows. Notes about no dive (a tag list, a site, the portrait) are on no row, and a client shows those in the list as before. A client can't make this join itself, because a note's uuid is the document's identifier, and the row's uuid is the stored dive's. Those differ for a remapped dive and for a dive that a later file's recording joins. Across a batch, two files can also give one uuid to two dives. So the join runs server-side on the batch member plus the document uuid. A note's member is traced by object identity rather than by position, because at the cap a later note can take a derived note's place and shift every index after it. A document dive whose recordings partly joined dives you already have puts its notes on the dive it became. record_remapped_references_stay is on no row, since its uuid names the first of the two records, not the remapped one. The change is additive, so the web build deployed now keeps rendering report.notes as it does today.

Verified with five new batch tests against Postgres: a sighting note on its created dive in both preview and apply, a dive whose stored uuid isn't the document's, two files sharing a dive uuid, a cap that shifts indexes, and a note about no dive. The import suites pass, as do ruff and all three mypy runs.

🤖 Generated with Claude Code