test: cover schedule signatory scope across account key changes

[ruslanvelkov-beep]

Adds test coverage for what a schedule's persisted signatories list means when account keys change between signing and execution. All four cases are new coverage; no production code changes.

Schedule.signatories (services/state/schedule/schedule.proto:165-181) stores only "primitive" keys, deliberately "regardless of signing order, intervening changes, or other situations", and requires that a scheduled transaction "SHALL execute only if, at the time of execution, this list contains sufficient public keys to satisfy the full requirements for signature". The suites already covered the case where requirements shrink so existing signatures become sufficient; these tests pin the surrounding invariants.

AbstractScheduleHandlerTest — four cases for the KEY_LIST/THRESHOLD_KEY recursion in accumulateNewSignatories, which had no unit coverage at all (keyList(/thresholdKey( appeared zero times in the module's tests):

• recordsOnlySigningConstituentsOfARequiredThresholdKey — constituents are recorded individually, whether or not the threshold is met
• recordsOnlySigningConstituentsOfARequiredKeyList — the key-list counterpart
• recordsSigningConstituentsOfANestedThresholdKey — recursion at depth
• doesNotRecordASigningKeyThatIsNotARequiredConstituent — signing is necessary but not sufficient; a key outside the required structure is not recorded

ScheduleSignatoryScopeTest (new, @HapiTest) — the same scope end to end:

• unrequiredKeyIsNotRecordedAcrossAKeyRotation — a key that was never required is not recorded, so rotating the sender onto that key later does not let the schedule execute; it executes only once that key signs while it is required
• aRecordedKeyAlsoSatisfiesAnAccountThatLaterAdoptsIt — documents the cross-account consequence of the flat primitive-key set: a key recorded for the sender also satisfies a receiverSigRequired receiver that later adopts it. No authority is created, since adopting a key needs signatures from both the account's existing key and the adopted key

RepeatableScheduleLongTermSignTest — growthInSigningReqsLeavesRecordedSignatoriesInsufficientAtExpiry, the complement of the existing reductionInSigningReqsAllowsTxnToGoThrough: a waitForExpiry schedule collects enough constituents to satisfy the key in force, the sender then raises its top-level threshold with the same constituents, and at expiry the schedule does not execute — the recorded signatories are re-checked against the current key and found insufficient. This is the only case in the suite exercising re-evaluation on the expiry-scan path.

Each new assertion was checked by inverting it and confirming the test turns red, so none of them passes vacuously.

Verified locally: :app-service-schedule-impl:test --tests "*AbstractScheduleHandlerTest" 8/8; :test-clients:testSubprocess --tests "*ScheduleSignatoryScopeTest" 2/2; :test-clients:testRepeatable --tests "*RepeatableScheduleLongTermSignTest" 14/14; spotless clean.

[lfdt-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

@@            Coverage Diff            @@
##               main   #27220   +/-   ##
=========================================
  Coverage     71.25%   71.25%           
- Complexity    11906    11907    +1     
=========================================
  Files          2596     2596           
  Lines        109552   109552           
  Branches      12364    12364           
=========================================
+ Hits          78061    78065    +4     
+ Misses        27447    27446    -1     
+ Partials       4044     4041    -3     

see 5 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[joshmarinacci]

👍

[testlens-app]

🚨 All tests passed but jobs failed 🚨

Failed Jobs without Test Failures

❌ 600: [FLOW] PR Checks / CI Complete
❌ 600: [FLOW] PR Checks / MATS / Snyk Scan / Snyk Checks
❌ 701: [FLOW] Auto Unapprove PR / Auto Unapprove PR

🏷️ Commit: b1cc30b
▶️ Tests: 32169 executed
⚪️ Checks: 28/28 completed

---

Learn more about TestLens at testlens.app/docs.