[release/6.x] Always emit transaction entry flag for primary-dictated chunks

[eddyashton]

See discussion in #7636 for motivation.

This is primarily a backport of #7097, which contains a stack of changes to move chunking decisions to a central in-enclave LedgerChunker, and using this rather than a per-tx flag on the in-memory Store to indicate that a chunk should be created at the next signature. The one big difference is that backups can still choose independently to create their own chunks, which will then not have the flag set in the transaction header. This version thereby creates a bridging release - it can interop with older nodes (consistent chunk threshold => consistent chunks on every node, decided locally by each backup), as well as with 7.x nodes (every chunking decision made by the primary is transmitted with the ledger, so that a peer can choose to rely on it authoritatively). This produces a few diffs in the unit tests between this branch and main, patched with a bit of trial-and-error reasoning.

[achamayou]

@eddyashton I suggest we add a line of INFO logging around https://github.com/microsoft/CCF/blob/release/6.x/src/host/ledger.h#L1434 which triggers if file->get_current_size() >= chunk_threshold && !force_chunk_after).

That will only trigger in:

1. a mixed pre-6.0.21/post-6.0.21 network if the primary is pre-6.0.21 (which is fine)
2. unexpected situations that warrant a closer look

[achamayou]

Genoa CI failure caused by primary unexpectedly stuck for a very long time trying to write something:

2026-02-03T17:42:28.778970Z        100 [info ] CCF/src/host/time_bound_logger.h:54  | Operation took too long (  2.781s): Writing ledger entry - 2119 bytes, committable=true

[eddyashton]

Genoa CI failure caused by primary unexpectedly stuck for a very long time trying to write something:

2026-02-03T17:42:28.778970Z        100 [info ] CCF/src/host/time_bound_logger.h:54  | Operation took too long (  2.781s): Writing ledger entry - 2119 bytes, committable=true

Took me a while to find this, since we had a green rerun after.

https://github.com/microsoft/CCF/actions/runs/21640210587/job/62377754657#step:6:244

Seems fishy, but so does everything.

[achamayou]

@eddyashton yeah I kicked it off again, because this is unrelated to this PR. It's unfortunate we have such I/O spikes on C-ACI, but I don't know what we can do about it. We've already shrunk the CI there to the bare useful minimum.

[eddyashton]

Converting this to draft for now, while we investigate #7637.