fix(ha-commit-engine,persist): reserve WAL lsn 0 — first entry starts at lsn 1

Root cause (found via live 3-node E2E + a verification test): lsn was 0-based
(hdr.lsn = current_lsn++ from current_lsn=0), and 0 was overloaded as a
sentinel, causing three cold-start defects on a freshly-promoted leader:
  - the first WAL entry (own-term promotion NOOP at lsn 0) was structurally
    uncommittable: commit_advance_locked only stores when cand>cur and
    committed_lsn starts at 0, so lsn 0 can never advance it;
  - commit_set_writable_lsn(noop_lsn=0) set writable_lsn=0, which wait_done
    reads as 'gate off' — the own-term safety gate was a no-op on the first leader;
  - bug-543 (WAL hole): ha_stream_wal_to_standby filters hdr.lsn>standby_lsn;
    a fresh empty standby reports standby_lsn=0 (ambiguous 'empty' vs 'has lsn 0'),
    so lsn 0 failed 0>0 and was dropped -> non-contiguous standby WAL.

Fix: a fresh persist store initializes current_lsn=1, reserving lsn 0 as the
none/empty sentinel. The first real entry is lsn 1 -> committable (0->1),
writable_lsn=1 -> gate effective, and standby_lsn=0 unambiguously means 'empty'
so catch-up streams from the first entry with no hole. persist_recover is
data-driven (current_lsn=max(hdr.lsn+1)), so existing on-disk WALs and non-fresh
recovery are unaffected; the change only sets the base for brand-new stores.
No wire/capnp change.

Verification: test_coldstart_lsn0 drives the real commit engine + real streamer
and proves H1 (first entry commits 0->1), H3 (gate effective + blocks when
committed<writable), H4 (empty-standby catch-up is contiguous [1,2], control
standby_lsn=1 gets only [2]). Full controller suite green under ASAN. Tests that
relied on the lsn-0 base were shifted (several strengthened); commit.c /
config_repl.c / ha.c / wire format untouched.

Owning specs: ha-commit-engine / ha-wal-replication / persist. Follow-up:
sweep stale lsn-0 comments (repl.c:429-436, persist.c:1055-1075/1240-1243/1296).

src/controller/persist.c

@@ -210,6 +210,22 @@ int persist_init(persist_t* p, persist_config_t* cfg, cluster_t* c)
     p->last_replicated_crc = WAL_CRC_NONE;
     p->last_crc            = WAL_CRC_NONE;
 
+    /* LSN 0 is RESERVED as the "none / empty" sentinel — it is NEVER assigned
+     * to a real WAL entry.  A fresh store therefore starts current_lsn at 1, so
+     * the first-ever appended entry (e.g. the promotion WAL_NOOP) is lsn 1 and
+     * lsn 0 unambiguously means "nothing here":
+     *   - committed_lsn == 0  → nothing committed (the lsn-1 NOOP is committable
+     *     0 → 1, vs. the old lsn-0 entry which could never advance committed_lsn);
+     *   - writable_lsn == 0   → own-term gate off (the gate armed at lsn 1 is
+     *     effective, vs. lsn 0 which read as "gate off" on a cold-start leader);
+     *   - standby_lsn == 0    → empty standby (the streamer's `hdr.lsn > 0`
+     *     filter streams the lsn-1 entry, closing the cold-start WAL hole that
+     *     dropped lsn 0 on `0 > 0`).
+     * persist_recover() overwrites current_lsn from the durable snapshot/WAL tip
+     * (load_snapshot / replay_wal), so this fresh default only applies before any
+     * recovery — i.e. a brand-new store with no snapshot and no WAL. */
+    p->current_lsn = 1;
+
     /* Enforce minimum value for max_wal_records to prevent runaway checkpointing */
     if (p->config.max_wal_records < 100) {
         ERROR("persist: max_wal_records=%u too low (minimum 100) — setting to 100",