fix(ui): isolate shrinking worker state

[DefiAudit0x]

Summary

Fixes #1601 by isolating the shrinking worker's mutable WorkerState from the reporting state used by the main fuzzing worker.

When a timeout triggers shrinking, the shrink-only pass starts from initialWorkerState. Reusing the same state reference causes the reporting counters to be reset to zero, so the final status can incorrectly report zero calls and zero gas even though the worker performed work before timing out.

This change gives the shrink-only agent a throwaway IORef initialWorkerState. The reporting reference remains owned by the main worker and is not overwritten by the shrinking pass.

Changes

• Added an explicit IORef WorkerState parameter to the fuzzer-agent construction path.
• • Added mkFuzzerAgent to make agent construction testable.
• • Updated the timeout shrinking path to use an isolated worker-state reference.
• • Added a regression test covering preservation of the reporting state across shrinking.

Validation

• Focused regression test: All 1 tests passed
• • Full Echidna suite: All 167 tests passed (630.81s)
• • git diff --check: passed
    The full suite was run after configuring the required libff, Foundry, Bitwuzla/Z3, solc 0.8.25, and Slither/crytic-compile dependencies. No unrelated tests were changed or weakened.

Scope

This PR is intentionally limited to the worker-state aliasing/reset issue described in #1601.

[DefiAudit0x]

Follow-up on the Windows CI result:

The only failing check is Test with solc 0.8.25 on windows-latest, where coverage/boolean.sol reports unexpected corpus count (1 of 167 tests). The same job passes all other tests, including the new Agent regression test, and the Ubuntu/macOS builds and solc matrices pass.

This failure is outside the scope of this PR: #1609 changes only the timeout-triggered shrinking worker state, while this coverage test does not exercise that path. The exact base master commit also passed the same Windows/solc 0.8.25 job previously. I reproduced the focused coverage test 20 consecutive times locally without the failure.

I prepared a separate test-only PR, #1610, which pins seed: 0 and workers: 1 in coverage/boolean.yaml; the focused test passed 10 consecutive times in an isolated baseline worktree. I have kept #1609 unchanged and separated the test-stability proposal so the worker-state fix remains narrowly scoped.