Function open_journal 

pub fn open_journal(
    path: &Path,
    journal: JournalMode,
    foreign_keys: ForeignKeys,
) -> Result<Connection, ReplicaError>

The journal-aware connection-opening ritual (journal negotiation + the hardening/ planner pragmas + regexp) moved to the apply plane (design 309): the headless apply store and every engine connection here must open IDENTICALLY, so there is one implementation. Re-exported at the historical paths — crate::parallel::open_journal is the embedded-engine seam’s public opener (design 308). Open one read-write connection (mirrors Db::open’s per-connection setup). Used for the apply store’s writer, the cluster coordinator’s writer, and each IVM worker.

foreign_keys is the connection’s enforcement posture and has no default here: an origin write plane (the standalone daemon, the HCTree master) says ForeignKeys::Enforced, an apply plane (a follower, a headless replay) says ForeignKeys::Unenforced because the rows it writes were already validated by the authority whose cascades are themselves in the stream. See [rindle_writeplane::foreign_keys] for the full argument, and rindle_writeplane::foreign_key_check for the audit that works either way.

Journal handling (design 306 D3/D5): under the default Wal request a file already in wal or wal2 is accepted as-is; anything else (a fresh file’s delete, a rollback-mode file) is converted to the requested mode. An explicit Wal2 request additionally attempts to convert a plain-wal file and — because the pragma silently reports wal when the switch cannot happen (an un-checkpointed WAL, other connections; docs/SQLITE_WAL2.md §10.3) — verifies the outcome and fails loudly rather than running a wal2-contracted daemon on a plain-wal store (the post-condition the retired open_wal2 enforced).