feat(loop): drive-session row tagging so ui_review teardown can drop drive-created rows (follow-up to #1121/#1118)

[mfittko]

Problem

Stage 5 of #1114 (/loop-review-ui, #1121) ships a teardown side-effect ledger + confirmation gate, but its dev-DB row-drop is honest-but-inert: the Stage-2 drive (#1118) does not tag the rows it creates (create/edit/upload actions) with a drive-session id, so teardown cannot know which rows to drop and — per #1121's Risk note — reports rows: may-remain-untagged rather than guessing. To make row-drop real, the drive must tag/emit the rows it created.

Task

Add drive-session row tagging in the Stage-2 drive so Stage-5 teardown can drop exactly the rows a drive created:

• The drive stamps each create/edit/upload it performs with a drive-session identifier (or otherwise records a row manifest), and emits that manifest in the drive result.
• Teardown consumes the manifest (--row-manifest already exists on scripts/loop/ui-review-teardown.mjs) and drops exactly those rows on confirmation — dev DB only, never production.

Acceptance criteria

• The Stage-2 drive emits a row manifest (or session-tagged row records) for the create/edit/upload actions it drives, in its result envelope.
• Stage-5 teardown drops exactly the manifested rows on --confirm (dev DB only); the ledger reports dropped with the count instead of may-remain-untagged.
• Untagged/absent-manifest path still fails closed to may-remain-untagged (never guesses).
• A test drives a fixture that creates rows, asserts the manifest is emitted, and that teardown drops exactly those rows on confirm.
• npm run verify green.

Non-goals

• Production row teardown.
• Migration rollback (separate explicit action; Teardown + side-effect ledger (Stage 5 of #1114) #1121 records migrations in the ledger, doesn't revert).

Notes

Follow-up to #1121 (Stage 5) and #1118 (Stage 2). The teardown ledger + confirmation gate + worktree/app teardown shipped in #1121; only the row-drop is inert pending this tagging.