fix: review follow-ups for security-release/candidate-1 (CI unblock + verified fixes)

[lrsaturnino]

Summary

Follow-up fixes for the review of threshold-network#4109 (security-release/candidate-1), stacked directly on its head dd2c87360. Clears the one merge blocker, applies the verified minor findings, and removes a second pre-existing red CI check that surfaced during validation.

What this fixes

• Merge blocker — pkg/bitcoin red at head. TransactionBuilder.getScript moved onto the new Transaction.OutputAt accessor, which changed the out-of-range error wording to "output index [N] is out of range ..."; transaction_builder_test.go still asserted the pre-refactor wording, leaving the package red. The alignment commit fixed spv_test.go/wallet_test.go but missed this one. Assertion aligned.
• pkg/bitcoin — Difficulty() division-by-zero. A malformed zero-mantissa Bits field, reachable from attacker-supplied headers on the SPV proof walk, made Difficulty() panic (contained only by the maintainSpv recover). It now returns zero difficulty for a non-positive target, so such a header contributes nothing and fails proof checks gracefully. Adds a regression test.
• pkg/beacon/event — incomplete TOCTOU remediation. The F-13 fix made the tbtc deduplicator atomic but left NotifyDKGStarted on the racy Has()+Add(), allowing two goroutines on the same seed to both proceed. Switched to the mutex-serialized Add, mirroring the tbtc deduplicator. Adds a concurrent regression test (passes under -race).
• RandomBeaconGovernance — tuple-destructure bug. finalizeAuthorizationDecreaseDelayUpdate destructured authorizationParameters() into the wrong position, binding the returned delay into the change-period variable and overwriting the stored change period with the old delay on finalize. Destructuring corrected to mirror the sibling change-period finalizer; the delay-finalize test now uses a distinct change period and asserts it is preserved.
• pkg/maintainer/spv — unused constant. The DIFF1 rewrite replaced epoch-length arithmetic with a header-difficulty walk, orphaning difficultyEpochLength, which trips the staticcheck CI job — a second pre-existing red check the review did not surface. Removed; the maxProofHeaders comment is also corrected (the beyond-cap outcome is a permanent skip, not a deferral).
• Docs. Document that the counter-based G1HashToPoint also diverges permanently from the immutable on-chain g1HashToPoint (verifyBytes / reportUnauthorizedSigning), a path with no in-repo callers, so the operational consumer is the off-chain GJKR Pedersen H generator. Make the flag-day requirement explicit (the breaking key-derivation, session-ID, and hash-to-point changes have no version gate, so a ceremony's node set must upgrade atomically). Note the clientInfo metrics port default change 9601 → 0. Correct the altbn128 test comment that claimed G1HashToPoint is used in relay-entry signing.

Deliberately not included: version-gated / negotiated activation for the breaking key-derivation changes was raised in review as an operational flag-day, not a code change. It is documented rather than implemented — bolting version negotiation into the crypto layer on a security release was out of scope.

Tests

All CI checks were replicated locally against the branch head:

• gofmt, go build ./..., go vet — clean
• golangci-lint v2.12.2 (CI-pinned) — 0 issues
• staticcheck 2025.1.1 with CI's -SA1019 — 0 issues
• go test — pkg/bitcoin, pkg/beacon/event (incl. -race), pkg/altbn128, pkg/maintainer/spv all pass
• random-beacon yarn build + RandomBeaconGovernance.test.ts — 275 passing, including the new change-period-preservation assertion