feat: allow FormRequest validation failures to reach controllers

[memleakd]

Description

FormRequest currently assume that a validation failure owns the response: either the default redirect/JSON response, or whatever the request returns from failedValidation().

That works well for many requests, but it is too rigid for server-rendered forms where the invalid response belongs to the controller action. Sometimes the controller already has the route context, loaded resource, page surface, or view composition needed to render the failed form correctly.

This PR keeps the default behavior unchanged. If failedValidation() returns a ResponseInterface, the framework still short-circuits and sends it immediately.

The only new path is that failedValidation() may now return null. In that case, the resolved FormRequest is injected into the controller, and the controller can handle the failed validation itself.

This avoids adding a second flag method or framework-owned error state. The request class can store whatever state the application needs, and the framework only needs to understand one thing: response means stop, null means continue.

Tests cover the default short-circuit behavior, the new controller-handled path, prepared validation data, and authorization still stopping before validation.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[michalsn]

A FormRequest parameter should mean "this request has been authorized and validated". Allowing failedValidation() to return null and continue into the controller weakens that contract, because the controller can now receive a FormRequest that did not pass validation. That feels surprising.

Also, failedValidation() can already return any ResponseInterface, including a rendered view or fragment response. So the common server-rendered form use case does not require continuing into the controller.

For cases where the controller really needs to handle invalid input, regular controller validation seems clearer and more explicit than using a FormRequest whose validation may have failed.

So, I don't think this is a good direction for FormRequest, but let's wait and see what others think.

[memleakd]

Thank you for the review @michalsn

After thinking about it more, I agree this is not the right direction for FormRequest. #10259 already covers the simpler HTML response cases, and the more context-heavy cases are probably better kept explicit in the controller.

I'm going to close this PR so we don't spend more review time on a direction that does not feel quite right.