test: make the sign suite and v118 pre-activation probe witness what they claim

[omersadika]

Two vacuous-pass fixes from the 1.2.0 release review (findings T2 and T3 in the review report) — both gate whether green runs of the release-validation suites actually witness the properties they exist for. Land before the pre-merge validation matrix runs.

Sign tests now assert the signature, not just the flow

The sign integration tests destructured the output and discarded it (RespondDWalletSign(_sign_output)) at all three sign sites plus the partial-signature site — while the create-dwallet and encrypt-share tests in the same suite assert !rejected. SignOutput.rejected is a legitimate response variant, so a network that rejects every signature kept the sign suite green, including the v118 workloads the release go/no-go leans on.

Now asserted at every site: !rejected plus non-empty signature bytes (sign_flow_test, future_sign_flow_test — both the partial-verification and completion steps — and the shared Fast-Schnorr external_vss_sign_flow). Cryptographic verification of the signature against the dWallet public key stays with the TS integration suite (hash-signature-validation), which already does it end-to-end.

v118 pre-activation probe pinned to the window it claims to test

v118_upgrade's pre-activation-window workload exists to witness one thing: global presigns served by the pre-pool fallback at protocol v3 on the new binary (the #1732 network-wedge rehearsal — a pending global presign at v3 blocks advance_epoch forever). The scenario comment says "while the network is still at v3", but nothing enforced it: if the capability vote lands early, the probe silently degrades into an ordinary v4 pool test and the run stays green.

Added expect_protocol_version_at_most(n) to the scenario harness (instantaneous ceiling twin of expect_protocol_version_at_least) and bracketed the probe with expect_protocol_version_at_most(3) before and after — the trailing ceiling is the load-bearing one, since the version can flip mid-workload. If the window ever closes early the run now fails loudly with a message saying exactly what was not witnessed, instead of losing the rehearsal silently. (v118_churn has no pre-activation probe — it starts its churn post-upgrade — so only v118_upgrade is bracketed.)

🤖 Generated with Claude Code

[omersadika]

T3 proof: v118_upgrade run 28577740468 green on this branch, and the log shows both ceiling assertions executed around the pre-activation probe:

[flow 7/20] >>> expect_protocol_version_at_most(3)
protocol version ceiling assertion passed got=3 expected_at_most=3
[flow 8/20] ... run_workload("pre-activation-window") ...
[flow 9/20] >>> expect_protocol_version_at_most(3)
protocol version ceiling assertion passed got=3 expected_at_most=3

The probe provably ran at protocol v3, and the trailing ceiling confirms the version did not flip mid-workload — the property the scenario's comment always claimed is now enforced, not assumed.

🤖 Generated with Claude Code