fix: [ENG-2851] seed review-backup before destructive tool-mode curate writes

Tool-mode `UPDATE`-shaped curates (CLI session protocol AND MCP
brv-curate) were creating `reviewStatus: 'pending'` log entries
without seeding the review-backup store. `brv review reject` then
treated the missing backup as ADD per `review-handler.ts:152` and
unlinked the file — destroying the user's prior content instead of
restoring it.

Add a shared `backupContextTreeFile` helper next to
`buildCurateHtmlLogEntry` and call it in both surfaces before
`writeHtmlTopic`. Mirrors main's `backupBeforeWrite` contract:
honors `reviewDisabled`, first-write-wins (snapshot at last push
preserved across multiple curates), ENOENT-safe (the ADD case is a
no-op), best-effort I/O.

CLI side now snapshots `reviewDisabled` once at continuation start
and threads it into both the backup decision and the log-entry
decision, avoiding a race against a mid-task `brv review
--enable/--disable` toggle.

Also addresses non-blocking review comments:
- agent-process.ts: split the JSON result back into an if/else (no
  trailing semicolon, matches the rest of the file)
- curate-html-log.ts: document why agent-asserted `meta.type` wins
  even when on-disk state contradicts it
- curate-session.ts: route the log-persistence catch through
  process.stderr.write so a user diagnosing "curate succeeded but
  `brv review pending` is empty" has a signal to grep