Clarify that a signal ban 403 does not stop the handler

[sascha-egerer]

No description provided.

[Copilot]

Pull request overview

This PR clarifies the behavioral contract around post-handler “signal bans” (via RequestContext::recordFailure() / recordHit()), emphasizing that enabling an opt-in 403 only changes the outgoing response and does not stop the handler/application from executing.

Changes:

• Clarifies that signal processing continues after a ban is imposed, while already-banned keys short-circuit subsequent signals for that same rule/key.
• Expands the enableBlockOnSignalBan() documentation to explicitly state that handler side effects have already occurred.
• Updates README and CHANGELOG to align user-facing documentation with the post-handler nature of signal bans.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/Middleware.php	Refines docblock wording for how recorded signals are processed and how the “first ban result” is selected.
src/Config.php	Clarifies the meaning and limitations of enableBlockOnSignalBan() in the API docs.
README.md	Adds explicit guidance that the opt-in 403 occurs after handler execution and does not prevent side effects.
CHANGELOG.md	Updates the “opt-in 403” entry to explicitly note that processing has already happened and aborting must be done in the handler if needed.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.