feat!: add structured poll interface for watch-towers

[mfw78]

The polling half of the dual-path architecture:

• generateOrder moves into IConditionalOrder as the shared source of truth
• GeneratorResult/GeneratorResultCode: poll() never reverts for order conditions, returning a structured verdict; fill state is deliberately absent from the generator surface (composed by the registry)
• getNextPollTimestamp / describeOrder hooks with base defaults
• revert decoding: only OrderNotValid is terminal; Panic, Error(string) and unknown reverts map to TRY_NEXT_BLOCK carrying the caught selector, so transient faults reschedule instead of permanently killing an order (closes polling: unknown reverts and Panic decode to permanent INVALID #3)
• tryGenerateOrder probe returns (success, order, revertData) as ordinary return data — full Panic sub-codes and inner-error arguments retrievable without RPC revert handling

BREAKING: the IConditionalOrderGenerator ERC-165 interface id changes; existing deployed handlers will not satisfy the new id.

Issues

Closes #3.
Advances #16 (lands the generator half - GeneratorResultCode / GeneratorResult; the orthogonal fill overlay that completes the split lands in #24).

Interface placement

generateOrder stays on IConditionalOrderGenerator rather than moving up to IConditionalOrder.

An earlier revision of this PR moved it into the base on the grounds that it is "the single source of truth for order derivation, shared by verify and poll". That reasoning does not survive scrutiny: verify() calling generateOrder() is how BaseConditionalOrder implements verify, not something the interface requires. generateOrder is public on the base, so verify reaches it as an ordinary member call, and nothing casts a handler to IConditionalOrder to call it -- the registry gates on type(IConditionalOrderGenerator).interfaceId before polling. The move was purely taxonomic and would have cost the distinction the split exists to express:

• IConditionalOrder -- verifies a discrete order. A handler whose order is fixed rather than derived implements this alone and is not pollable.
• IConditionalOrderGenerator -- derives discrete orders on-chain, possibly a series of them (TWAP), and is therefore pollable by a monitoring service.

Promoting generateOrder to the base would have made derivation mandatory for every handler and left the generator interface named after a capability it no longer carried.

The divergence risk that motivated the move is real and is addressed directly instead: the generateOrder NatSpec now states that a generator's verify MUST accept exactly the orders it produces, since the two are separate call paths and a mismatch lets a watch-tower propose an order settlement rejects. Non-generators carry no such obligation.

test/ComposableCow.base.t.sol's MirrorConditionalOrder is the concrete non-generator case and keeps the plain IConditionalOrder shape covered.

Error placement

Only OrderNotValid stays on IConditionalOrder: verify raises it directly (BaseConditionalOrder.sol on hash mismatch), so it is not generator-specific.

The polling errors (PollTryNextBlock, PollTryAtBlock, PollTryAtTimestamp) move down to the generator. They are raised only from generateOrder implementations and decoded only by _decodeErrorToPollResult; a plain IConditionalOrder handler is never polled, so a reschedule hint from its verify would have no consumer.

This does not change any selector: Solidity derives an error selector from its signature, not from the interface that declares it. The ABI is untouched and only the qualified Solidity reference changes.

Part of #1.