feat: prepare invariant campaigns for sharding

[0xKarl98]

On first step for OSS-273 ,

Adds the minimal structure needed to treat an invariant contract as one logical campaign that can later be split across workers.

The execution path is still single-worker. This PR only introduces the campaign/worker/result boundary so future PRs can partition runs across --jobs workers and merge worker outputs back into one contract-level invariant result without changing user-facing behavior

cc @grandizzy @mattsse @figtracer @mablr

[0xKarl98]

@mablr @figtracer have addressed your concerns , ptal again

[mattsse]

LGTM

[grandizzy]

since we're here let's first cleanup the suite test outcome, e.g. when running with show-progress there's still the invariant anchor which is no longer needed, see below - there are multiple invariant fns defined in each contract (see https://github.com/grandizzy/invariant-output to test / try)

Then same on output, the invariant_stakingSolvent should be replaced by contract name maybe?

Also, the BuggyBank contract with 4 invariants, designed with 3 passing and one failed:

• ✅ invariant_actorsRegistered
• ✅ invariant_bankHoldsNoEth
• ✅ invariant_countersMatchHandlerActivity
• ❌ invariant_ledgerConserved (fails by design)

the output is misleading and quite hard to interpret as all invariants are marked failed. It also shows the invariant table metrics several times instead only one time as in case of success.

[grandizzy]

lgtm!

[mablr]

Nice