fix: coalesce ledger WAL flushes and extend to non-authority nodes

[skylar-simoncelli]

Overview

Note: This PR is based on feat/ledger_enact_parity_db_logs and should be reviewed alongside that branch. It adds three improvements to the ledger parity-db WAL flush task.

Changes

1. Flush coalescing (prevents task queue buildup)

The current code in feat/ledger_enact_parity_db_logs spawns a new spawn_blocking task for every BlockOrigin::Own notification. If a flush takes longer than the 6-second block interval, tasks accumulate without bound.

Added an AtomicBool flag (flush_in_progress) — if a flush is already running when the next notification arrives, we skip rather than spawn another task. This guarantees at most one flush is running at any time.

2. Non-authority node coverage

The current code only flushes on BlockOrigin::Own, which means non-authority nodes (RPCs, bootnodes, bridges, semi-trusted RPCs) never trigger a flush. Their ledger WAL grows until the 64 MB threshold causes a synchronous stall, which can cause:

• RPC request timeouts
• Peer disconnections when the node appears unresponsive

Non-authority nodes now flush every 50 imported blocks — frequent enough to prevent WAL buildup, infrequent enough to avoid excessive I/O.

3. Task moved outside authority gate

The flush task is no longer inside if role.is_authority(), so it runs on all node types.

Relationship to other PRs

• Based on: feat/ledger_enact_parity_db_logs (ledger WAL flush on block import)
• Companion to: fix: ensure parity-db WAL is drained on SIGTERM shutdown #1140 (Substrate chain DB shutdown drain fix)

Together these two fixes address the full parity-db WAL problem:

• feat/ledger_enact_parity_db_logs + this PR → prevents runtime WAL stalls on both authority and non-authority nodes
• fix: ensure parity-db WAL is drained on SIGTERM shutdown #1140 → prevents chain-state truncation on shutdown

Context

Discovered during investigation of chain-state truncation after unclean shutdown (#1140). While testing on guardnet, we measured every node having ~9,000-10,000 blocks of metadata sitting only in the WAL at any given time, confirming the WAL accumulation problem.

📌 Submission Checklist

• Changes are backward-compatible (or flagged if breaking)
• Pull request description explains why the change is needed
• Self-reviewed the diff
• I have included a change file, or skipped for this reason: improvement to unreleased feature branch
• If the changes introduce a new feature, I have bumped the node minor version
• No new todos introduced

🧪 Testing Evidence

Logic-only change to an unreleased feature. The coalescing and interval flush are safe additive behaviors on top of the existing flush mechanism.

🔱 Fork Strategy

• Node Client Update