## Summary

Fixes #362 — PBSS diskRoot stuck at genesis causing crash-resume and snapshot restore failures.

## Problem

The P1 checkpoint trie commit at every 900-block epoch boundary was gated behind `XdcBulkSyncMode.Load()`, meaning it only fired during bulk sync. For nodes running in normal operation or restored from snapshots, no explicit trie commit ever happened, leaving the pathdb `diskRoot` stuck at its genesis value.

On restart, the startup recovery code reads `diskRoot` from the account trie node at empty path. Since this was never updated post-genesis, the node could not find a matching block during snapshot walk-back, causing:
- `ERROR snapshot walk-back exceeded safe limit without finding a checkpoint snapshot`
- Sync resume failure after unclean shutdown or snapshot restore

## Root Cause

`writeBlockWithState()` had an early return for PBSS mode that skipped `bc.triedb.Commit()`. While upstream geth relies on pathdb's automatic buffer flushing, XDC's modified validation flow combined with the bulk-sync-only checkpoint commit left the disk layer root stale.

## Fix

Remove the `XdcBulkSyncMode.Load()` gate so the checkpoint commit fires during both bulk sync AND normal operation for XDC chains (chain IDs 50 and 51). The commit uses the cached GP5 root (from PR #350) when available, ensuring trie nodes are persisted under the correct root.

### Changes
- `core/blockchain.go`: Modified the P1 checkpoint commit block to remove the `XdcBulkSyncMode.Load()` condition

## Test Evidence

This fix ensures:
- The account trie root node is written to disk every 900 blocks
- `rawdb.ReadAccountTrieNode(db.diskdb, nil)` returns the current root after restart
- The journal remains valid across restarts
- Both crash-resume and snapshot restore can find a consistent disk root

## Related

- Closes #362
- Related: #308, #311, #312, #60, #190