Prioritized and injected transaction sequences

[elopez]

A prototype is a SolCall with holes: a function name plus an argument
list where Nothing marks an argument the fuzzer should fill in. This PR
teaches the generator to build transactions from prototypes, and teaches a
fuzzing worker to accept a sequence of them over the inter-worker bus and
spend part of its budget fuzzing that ordering instead of a corpus-mutated one.

The point is to let something outside the campaign say "this ordering looks
interesting" — an ordering the corpus mutators are unlikely to stumble into on
their own — without pinning everything else about the sequence.

Nothing sends these commands yet; the client that does arrives with the MCP
server. Until then the entry points are genTxFromPrototype and
genPrioritizedSeq.

Commits

Worth reviewing in order — the first is a pure refactor and carries no
behaviour change:

1. refactor: factor the shared tail out of genTx — genTx resolved the
   deployed contracts, picked one and generated a call, then wrapped it in a
   Tx. Only the middle step is about choosing what to call, so the two ends
   become callableContracts and toTx, with genRandomCall in between.
2. feat: generate a transaction from a call prototype — SolCallPrototype,
   genTxFromPrototype, matchingContracts, genPrototypeCall.
3. feat: prioritize injected call sequences during fuzzing —
   genPrioritizedSeq, WorkerState.prioritizedSequences, the FuzzSequence
   and ClearPrioritization commands, and the randseq split.

Notes on the design

genPrioritizedSeq generates the prototype calls in order with up to
maxInterleavedTxs random transactions between consecutive ones, prefixes the
result with the start of a corpus entry so the ordering also runs from a state
the campaign has already reached, then pads or truncates to seqLen. Worker 0
always takes the empty prefix, so the ordering stays covered from the initial
state too.

Matching a prototype against the deployed contracts is on name and arity
only — an argument left open carries no type to compare against, so
same-arity overloads all qualify and one is picked at random. This is
documented at matchingContracts. When nothing exposes the named function the
generator falls back to a fully random transaction, so a prototype naming a
function that isn't there costs diversity rather than stalling the worker.

SolCallPrototype lives in Types.Signature next to SolCall, so
Transaction, Campaign and InterWorker share one name for it.
genPrioritizedSeq sits next to genTxFromPrototype in Echidna.Transaction,
and the two new command handlers go in Worker/Command.hs alongside the
sampling ones rather than back into runFuzzWorker's where block.

Two things to flag

• prioritizedSequences is uncapped, unlike sampledFunctions which
  maxSampledFunctions bounds. It only grows via bus commands and randseq
  walks it with rElem on the hot path, so a client injecting repeatedly grows
  it without bound; ClearPrioritization is the only reset. Happy to add a cap
  for symmetry with the sampling handler if reviewers prefer.
• Truncation can cut prototype calls. When the expansion alone exceeds
  seqLen, take seqLen drops its tail, so a prototype longer than seqLen is
  only partly exercised. Pre-existing behaviour, preserved here.

Verification

cabal build is warning-free, hlint lib src is clean (the one remaining hint
is pre-existing in SourceMapping.hs), and all 190 tests pass. Each commit
builds on its own, so the branch stays bisectable.

Since nothing enables the feature until the MCP server lands, the new path was
also driven directly:

• every generated sequence is exactly seqLen, with the prototype calls present
  in order and with the fixed arguments they were given;
• a prototype naming a missing function falls back without ever producing that
  call, still at seqLen;
• worker 0 never takes a corpus prefix, worker 1 does;
• end to end, a real campaign with FuzzSequence pushed over the bus breaks an
  ordering-dependent property that a 20,000-tx baseline run does not.