Generalize the Render Response server-push requirement to allow modern mechanisms (HTTP 103 Early Hints)

Nobody has claimed this yet.

### Summary

§2.2.6 "Render Response" (`RequestProcessingLifecycle.adoc`, anchor `a457`) normatively requires the runtime to push view resources to the client using the **Jakarta Servlet Server Push API**. That API (`jakarta.servlet.http.PushBuilder` / `HttpServletRequest.newPushBuilder()`) is now deprecated, and the transport it relies on — HTTP/2 Server Push — has been abandoned by browsers. This issue proposes rewording the requirement to be mechanism-neutral so implementations can use a current mechanism such as HTTP 103 Early Hints.

### Current spec text

> If running on a container that supports Jakarta Servlet 4.0 or later, after any dynamic component manipulations have been completed, any resources that have been added to the UIViewRoot, such as scripts, images, or stylesheets, and any inline images, **must be pushed to the client using the Jakarta Servlet Server Push API.** All of the pushes must be started before any of the HTML of the response is rendered to the client.

Introduced by #1436.

### Problem

- **The named API is deprecated.** `jakarta.servlet.http.PushBuilder` and `HttpServletRequest.newPushBuilder()` are marked `@Deprecated` in Jakarta Servlet. A spec `must` cannot mandate a deprecated API.
- **HTTP/2 Server Push is dead in browsers.** Chrome removed support in Chrome 106 (Oct 2022); other major browsers never shipped it. The pushes Faces issues today are silently ignored, so the `must` mandates a no-op.
- **The requirement is over-specified.** It hard-binds resource hinting to one transport. The goal — proactively informing the client about resources before the HTML is rendered — is transport-independent.

### Modern replacement already exists

Jakarta Servlet provides a standard, non-deprecated API for HTTP 103 Early Hints (RFC 8297):

- `HttpServletResponse.SC_EARLY_HINTS` (103)
- `HttpServletResponse.sendEarlyHints()`

combined with `Link: ; rel=preload` response headers. This is the actively-supported successor and is honored by current browsers.

### Proposed resolution

Reword the §2.2.6 bullet to be mechanism-neutral, e.g.:

> After any dynamic component manipulations have been completed, any resources that have been added to the UIViewRoot, such as scripts, images, or stylesheets, and any inline images, **should** be proactively communicated to the client using a server-push or resource-hint mechanism provided by the container — for example HTTP 103 Early Hints (RFC 8297) or HTTP/2 Server Push. Any such hints or pushes must be issued before any of the HTML of the response is rendered to the client. The choice of mechanism, and whether to perform this optimization at all, is left to the implementation and the capabilities of the underlying container and connection.

Notable changes:
- Drop the reference to the deprecated "Jakarta Servlet Server Push API"; name 103 Early Hints and HTTP/2 Server Push as non-binding examples.
- Soften `must` → `should`: the optimization is best-effort and depends on container/connection support, so a hard `must` is not portably testable.
- Drop the "Jakarta Servlet 4.0 or later" version gate, since the available mechanisms now vary by container version.

A corresponding ChangeLog entry should record this, superseding the #1436 entry.

Start in RequestProcessingLifecycle.adoc at §2.2.6 and anchor a457, then inspect the existing ChangeLog entry introduced by #1436. Update the requirement to be mechanism-neutral while preserving its resource-timing intent, and add a corresponding ChangeLog entry that supersedes #1436. Done means both specification text and change history reflect the agreed wording.

Written by the indexing model from the issue text.