Release execution after queuing normal superblock seals

[bmuddha]

Outcome

Normal superblock boundaries resume execution after taking a coherent snapshot and successfully queuing the seal. The appender completes the existing durable seal and rotation asynchronously, while FIFO ordering places all subsequent ledger events in the successor superblock.

Scope

• Keep the sequencer barrier through snapshot creation and successful Superblock event enqueue, then release it without waiting for an additional appender Sync.
• Keep the seal's existing data-file and index durability, file finalization, and superblock rotation inside the appender.
• Increase the bounded appender queue capacity to 2,048 entries while leaving the reader queue independently sized.
• Preserve explicit synchronous fences for shutdown, replay completion, replication reconnect/bootstrap, reset, and retention.
• Update boundary-completion contracts and comments that currently describe a normal superblock submission as synchronously sealed.

Acceptance criteria

• A normal superblock boundary does not enqueue Sync after Superblock and does not wait for the appender to finish sealing before execution resumes.
• The Superblock event is queued while the sequencer barrier is held, and appender FIFO ordering keeps preceding events in the sealed segment and subsequent events in its successor.
• The appender queue is bounded at 2,048 entries, applies backpressure when full, and does not change the reader queue capacity.
• The appender still durably syncs and finalizes the sealed files and index before publishing the rotation.
• Shutdown, replay, replication reconnect/bootstrap, reset, and retention continue to wait for their explicit durability fences.
• Appender failures remain process-fatal and cannot silently drop queued work.