Request APIs After An Await Throw E1378 On Client Disconnect — But Only If `After()` Was Called Earlier In The Request

`AfterContext.after()` registers the current work-unit store. On response close, `onClose` sets `phase = 'after'` only for stores that called `after()`. When a page component resumes after the response has closed, its `phase` is already `'after'`, causing `isRequestApiAllowedInCurrentPhase` to reject request APIs. The error is conditional on both arming and a race, making it hard to reproduce and attribute.

1. Create two identical dynamic routes, one calling `after(() => {})` before an await and one without. 2. Use `curl --max-time 1` to abort requests to both routes. 3. Observe server logs: the route with `after()` logs E1378 after ~5s, while the other does not.

This change alters the contract: previously, any use of request APIs in a page after response close would throw if `after()` was called. With this fix, such uses are allowed. This could hide real bugs if developers rely on the error to detect late access in scenarios where data might be stale. However, headers and cookies are immutable during a request, so the risk is minimal. Ensure that the `WorkUnitStore` type includes `'after'` in your version; if not, adjust the type guard accordingly. Rollback: revert this function to the original implementation (reject all `phase === 'after'` stores) if unexpected regressions occur.