execution/commitment: record the trunk-preload duration and bytes counters

[lystopad]

Problem

commitment_trunk_preload_duration_seconds_total and commitment_trunk_preload_bytes_total are declared in trunk_pin_metrics.go but never written anywhere in the tree, so both read 0 for the life of the process.

Confirmed on a live Gnosis node with 5.9 days of uptime and 68,732 recorded preload extensions:

commitment_adaptive_pin_extended_total 68732
commitment_adaptive_pin_promoted_total 5137
commitment_branchcache_pinned_entries  118337
commitment_trunk_preload_bytes_total            0   <-- never written
commitment_trunk_preload_duration_seconds_total 0   <-- never written

The neighbouring counters work; only these two are dead. The result is that there is no metric signal for how much work the adaptive pin controller does or how long it spends doing it. That gap was noticed while diagnosing #23066 — a livelock inside ContractTrunkPreloadParallel.Run — where these counters would have been the natural place to see preload time climbing.

Change

Record both at the two places a preload actually runs, covering the parallel and serial paths in each:

• promoteLocked — the initial view for a newly promoted contract.
• runExtensionLocked — the per-block extension step, which is the dominant path in a running node.

A promote whose Run fails has its pins rolled back via Invalidate, so it contributes its duration but no bytes. That is why recordPreload takes the byte count as a parameter instead of reading it back off the preloader.

No behaviour change beyond the counters; no new metric names, cardinality, or hot-path work (both call sites already run once per contract per block under c.mu).

Testing

TDD, red → green. Both tests fail on main with the counters flat at 0:

• TestAdaptivePin_PromoteRecordsPreloadMetrics — both counters advance across a promote.
• TestAdaptivePin_ExtendRecordsPreloadMetrics — both counters advance across an extension, with the initial view budgeted so the queue survives promotion and there is real work left to measure.

Each test guards against a vacuous pass by first asserting the preload actually pinned bytes / left a non-empty queue.

Full execution/commitment/... suite passes. make lint clean for the touched files.

Relationship to #23066

Split out of #23066 review discussion to keep that fix minimal. The two branches touch disjoint files (adaptive_pin.go / trunk_pin_metrics.go here, preload_parallel.go there). Verified by trial-merging the two branches: no conflicts, merged result builds and the full package suite passes. They can land in either order.