refactor(recovery): replace single-page journal slot with multi-page sidecar

The previous design stored the apply-journal record inside main.db pages
2/3 (one page, parity-selected), capping the promotion/tombstone set to
what fits in a single page body and conflating journal state with the
free-list region.

The new design writes a standalone AEAD-authenticated sidecar at
applyjournal/<hex(journal_id)>. A 32-bit stream-length prefix makes the
record self-delimiting across an arbitrary number of pages, so the
action set is unbounded. Each apply allocates a fresh journal_id whose
two halves are packed into the header's existing
apply_journal_root_{page_id,version} fields; an all-zero id means no
apply is in flight.

Replace encode_apply_journal / decode_apply_journal with:
  encode_record        – serialise the record bytes
  encode_journal_pages – split into page-sized bodies with length prefix
  decode_journal_stream – parse from the concatenated page stream
  encode_journal_id / decode_journal_id – pack/unpack the 16-byte id

Update replay_apply_journal to accept a Pager + RealmId so it reads
through the AEAD path rather than making raw VFS reads.

Author: farhan-syah