fix(keeper): drop stale watches and idle duplicate rejections

[mfw78]

What

Fixes two watch-lifecycle bugs in the keeper's cow::run poll loop and adds permanent-drop observability:

• submit_ready (crates/shepherd-sdk/src/cow/run.rs): an OrderCreation constructor rejection (validTo beyond the client-side one-year horizon, zero from) no longer skips-and-keeps the watch in an unbounded per-block eth_call + Warn loop. It now routes through the Retrier as Drop, matching watch-tower parity. The unknown-enum-marker case keeps its existing skip-and-keep behaviour, since an SDK upgrade could still pick that watch up. New test ready_beyond_the_valid_to_horizon_drops_the_watch asserts zero submits, the watch dropped, and a warn logged.
• Stop-loss (modules/examples/stop-loss/src/strategy.rs): a DuplicatedOrder rejection is now special-cased ahead of classify_api_error via is_already_submitted. It writes the submitted:{uid} marker the dedup guard reads and idles, instead of re-posting the same order every block until validTo. New regression test duplicate_rejection_records_receipt_and_idles.
• twap-monitor's poll_one and the keeper run loop's DontTryAgain arm now log the four-byte revert selector and the node's message before a watch is permanently dropped, so a wrongly-dropped watch is triageable from the log alone.
• Adds a free nexum_sdk::keeper::watch_key helper (no host turbofish needed) and switches call sites (including twap-monitor's test-only watch_key) over to it; drops the now-unneeded shepherd-sdk dev-dependency from shepherd-backtest and nexum-sdk-test.

Why

Two skip-and-keep paths left a watch alive indefinitely once it reached a state that could never resolve: an OrderCreation constructor rejection is deterministic for the polled payload, so keeping the watch just re-polled and re-warned every block forever, and a duplicate-order rejection meant the orderbook already had the order, so re-posting on every subsequent block was pure waste. Both now converge on the watch-tower's actual behaviour (drop on an unrecoverable rejection, idle once the receipt is recorded), and the added selector/message logging means a dropped watch does not need to be reproduced to work out why it was dropped.

Part of the M1 keeper sweep (#135).

Testing

Full gate battery run inside nix develop, mirroring just ci:

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features --locked -- -D warnings
• RUSTDOCFLAGS=-D warnings cargo doc --workspace --no-deps --locked
• cargo build --release --target wasm32-wasip2 --locked across all example/module targets
• cargo test --workspace --all-features --no-fail-fast --locked, including the new ready_beyond_the_valid_to_horizon_drops_the_watch, duplicate_rejection_records_receipt_and_idles, and the twap-monitor revert-selector log assertions

AI Assistance

Claude (Opus) used for the implementation.

[lgahdl]

The three fixes are correct and the tests are solid. A few items below.

[lgahdl]

This guard still fires on real fixtures: any fixture whose app_data_resolved is None (collected before hash-only submission, or whose hash 404'd) returns RejectedExpected("app_data hash not mirrored") regardless of what the strategy actually did. A fixture that the strategy fails to submit for a completely unrelated reason (watch drop, gate, etc.) will be silently misclassified as expected-skip rather than landing in RejectedUnexpected for triage.

Either remove the guard (the RejectedUnexpected bucket is the right place for it now) or invert the condition to fx.app_data_resolved.is_some() so it only fires for fixtures that actually had resolved data — but the label still needs updating in that case.

[lgahdl]

Permanent watch removal warrants warn, not info. The comment above correctly says sources may not log their own outcomes — for such a source the only signal that a watch vanished forever is this line, and at info level that's easy to miss in production logs.

Suggested change

	// for sources that do not log their own outcomes.
	tracing::warn!("{} dropped watch {}", source.label(), watch.key());

[lgahdl]

This correctly writes to dedup_key (submitted:{uid_hex}), but the normal-submit success path a few lines above writes submitted:{server_uid} instead. If the server returns a UID that differs from the client-side uid_hex (the drift path that already logs a warn), the dedup guard reads dedup_key and will not fire next block — the module re-POSTs until validTo. The DuplicatedOrder fix here closes that window correctly, but the root asymmetry in the success path is now visible by contrast. The chassis submit_ready uses the client UID consistently on both paths.

[lgahdl]

The advisory about chain-adders is buried mid-sentence in the None return-value description, making it hard to scan. Consider moving it to a # Note section so the None condition can be read on its own.

Suggested change

	/// on such a chain - bounded, but callers adding new chains should
	/// on such a chain — bounded, but bounded only by `validTo`. New chains
	/// should be registered in `cowprotocol::Chain` before go-live.