Validate `BackForwardGoToItem` against the dispatching connection

The check fired, and the process that failed it kept running.

Component: WebKit UIProcess IPC | 09efe9e

WebKit's UIProcess treats every incoming IPC message from a sandboxed, potentially compromised WebContent process as untrusted, and the MESSAGE_CHECK/MESSAGE_CHECK_BASE macros enforce protocol invariants by marking the sending Connection invalid — a flag Connection::dispatchMessage later reads to trigger didReceiveInvalidMessage() and kill the offending process. During a cross-site navigation WebKit performs a process swap, briefly keeping both the committed process and a ProvisionalPageProxy's new process alive, so BackForwardGoToItem can legitimately arrive on either connection.

This commit fixes the check being performed against WebPageProxy::legacyMainFrameProcess() rather than the IPC::Connection that actually dispatched the message. The real Connection is threaded down through ProvisionalPageProxy and WebBackForwardList so that backForwardGoToItemShared() can call MESSAGE_CHECK_BASE against it, and the now-unused connectionForProcess() workaround is removed.

  Provisional process ──► BackForwardGoToItem ──► backForwardGoToItemShared()
                                                    │
  Before: MESSAGE_CHECK_BASE( ..., legacyMainFrameProcess()->connection() )
                                                    └──► invalid flag set on the
                                                         COMMITTED connection
                                                         (never dispatched again
                                                          for this message)
  After:  MESSAGE_CHECK_BASE( ..., connection )     └──► invalid flag on the
                                                         dispatching connection
                                                         ──► didReceiveInvalidMessage()

Significance

Because the invalid-message flag was set on the wrong Connection object, the process-termination path silently never fired for BackForwardGoToItem messages arriving on a provisional process's connection. A validation macro that marks the wrong object fails open: the check runs, the check fails, and nothing happens.

Audit directions

The pattern worth hunting is a MESSAGE_CHECK_BASE whose connection argument is recovered from page or process state rather than from the message's own dispatch context. Narrow: audit the other WebPageProxy and WebBackForwardList handlers that reach MESSAGE_CHECK_BASE through a helper several frames below the receiver, since that is where the connection tends to get re-derived instead of passed. Wider: process-swap windows are the general hazard — any UIProcess handler reachable during a provisional load has two live connections to choose from, and choosing by convention rather than by parameter is the bug; the ProvisionalPageProxy message surface is the natural starting list. Widest: a security control that reports failure by mutating an object identified separately from the operation being checked can always be made to report against the wrong object. Code-review tell: a MESSAGE_CHECK_BASE whose last argument is a call expression like someProcess()->connection() rather than a connection parameter already in scope.

---