feat(rejection): let the workflow continue after a rejection

[maia-andre]

Part of #8405. This is the second of the three pull requests agreed in the issue: #8423 brought the policy model, this one brings the behavior, and the third will adapt #8398 to rejection_visibility and settings.canSign.

📝 Summary

With rejection_behavior = continue, a rejection no longer stopped the other signers. Nothing after that point knew about rejected signers, though. The file could never finish, the signer who refused was still offered the signature, and in a sequential flow the signers after them waited forever. This PR covers the items that step 2 of the issue lists:

• continue completes the file. When every signer is SIGNED or REJECTED and at least one of them signed, the file becomes SIGNED. No new FileStatus is added, and the rejected signer keeps its own REJECTED status. The behavior comes from the configuration frozen on the request, so a later policy change cannot complete an existing workflow or reopen it. Observers were already left out of that evaluation.
• A rejected signer cannot sign later. SignFileService refuses the attempt with its own message. FileListService stops counting rejected signers as pending, and the file list stops offering them the button.
• settings.canSign is false for rejected signers, for observers, and for a signer whose turn has not come. SignersLoader now applies the rules that SignerValidator enforces at signing time. The request must be ABLE_TO_SIGN and belong to a signing participant. In an ordered flow, no signer with a lower order may still be pending. Before this change, a DRAFT signer waiting for their turn was offered a signature that the endpoint then refused.
• A rejection releases the next order in a sequential flow. SignatureRejectionService calls SequentialSigningService::releaseNextOrder() inside the rejection transaction, for every document the signer rejected, so an envelope releases the next order on each of its documents. isOrderFullyCompleted() treats REJECTED as done, the same way hasPendingLowerOrderSigners() already did. If the release fails, the rejection rolls back.

cancel is unchanged: the rejection still closes the file, and none of the code above runs.

Composition and reading order

+582/−11 in 11 files. About 117 of those lines are production code and 465 are tests (unit tests and one Behat scenario). There is no generated code: the response shapes do not change, and composer openapi produces no diff.

The commits can be read one by one:

1. feat(rejection): complete the workflow when a rejection does not cancel it: SignFileService (start here)
2. fix(rejection): keep a rejected signer out of the signing flow: SignFileService, SignersLoader, FileListService
3. test(rejection): cover the continue behavior end to end: a new scenario in reject.feature
4. fix(sign): offer the signature only when it is the signer's turn: SignersLoader
5. fix(rejection): release the next signing order when the workflow continues: SignatureRejectionService, SequentialSigningService

❓ One point for you

When every signer rejects, no signature exists, and the file is left as it was. The issue requires at least one signature before a file can complete, and it rules out a new status for this case, so this PR does not decide it. Should the file stay as it is, should it be canceled like with cancel, or should this be tracked separately?

🧪 How to test

The Behat scenario in tests/integration/features/sign/reject.feature covers the parallel case end to end:

cd tests/integration
vendor/bin/behat features/sign/reject.feature -v

Two signers, with rejection_enabled = true and rejection_behavior = continue. The first signer rejects, and the response carries workflowCanceled: false. That signer is no longer offered the signature, and a direct signing request from them is refused. The second signer signs, and the file reaches SIGNED while the signers keep REJECTED and SIGNED.

Unit tests cover the sequential flow: turn handling in canSign, releasing the next order after a rejection, envelopes, and rollback. To check it by hand:

1. Allow rejection with continue (the rejection_enabled and rejection_behavior policies).
2. Request a signature from three signers with signing orders 1, 2 and 3.
3. As signer 1, reject. Signer 2 now receives the request, and settings.canSign becomes true for them.
4. Signer 3 still sees settings.canSign = false until signer 2 signs. When signer 3 signs, the file becomes SIGNED.

⚙️ API / Back‑end changes

• File status: with continue, the file becomes SIGNED once every signer has signed or rejected and at least one signature exists
• Signing endpoint: refuses a signer who has already rejected
• settings.canSign: false for rejected signers, observers, and signers whose turn has not come
• Sequential flow: a rejection releases the next order
• Unit and/or integration tests added – required for backend changes
• Capabilities updated (if applicable): not applicable
• Documentation updated (if applicable): the rejection behavior will be documented once the three PRs land
• API documentation updated with the command composer openapi if necessary: ran it, no diff

✅ Checklist

• I have read and followed the contribution guide.
• Focused PHPUnit runs: SignFileServiceTest, FileListServiceTest, SignersLoaderTest, SignatureRejection/, SequentialSigningServiceTest
• php-cs-fixer and psalm are clean on the changed files

🤖 AI (if applicable)

• The content of this PR was partially or fully generated using AI