Drop two banned constructions from the R1 text and one from Path B

docs/plans/2026-08-19-frontend-simplification.md

@@ -43,7 +43,7 @@ OAuth sits outside that criterion as the flow is built today, and no frontend ch
 inside. The provider callback lands in a popup, which is a top-level context of its own, so the
 cookie set there is keyed to the auth host and not to `food.com`, and the frame embedded in
 `food.com` is a different partition that never sees it. `SameSite` compounds it, being judged
-against the top-level site rather than against the request's own origin, and the cookie is
+against the top-level site and not against the request's own origin, and the cookie is
 `HttpOnly` besides, so the popup cannot read it to hand it over. None of that is a defect; it is the
 partitioning model behaving as specified. Bringing OAuth inside the criterion needs the
 server-mediated handoff described in the constraints below, where the popup posts a one-time code
@@ -75,8 +75,8 @@ vacuously. Telegram is the one of the three still resting on inference. It is ex
 cannot be until #2208 makes the Telegram API base URL configurable, because without that the stack
 cannot answer as Telegram; `go-pkgz/auth` #316 is the change that would let the suite measure it. The
 inference itself is that the client-side writer keys off `X-JWT` on any auth response and not off the
-provider, so nothing in it distinguishes one flow from another. Worth naming which of the three is
-inferred, because a criterion resting on flows the suite cannot reach is a milder version of the
+provider, so nothing in it distinguishes one flow from another. The distinction is worth keeping
+visible, because a criterion resting on flows the suite cannot reach is a milder version of the
 defect this section was rewritten to remove.
 
 `ALLOWED_HOSTS` sets the CSP `frame-ancestors` and `AUTH_SAME_SITE=none` lets the server's auth
@@ -218,7 +218,7 @@ skipped entirely. That would put a live JWT into `Referer`, into history, and in
 the route is one that logs bodies. It is unreachable in any case, since the JWT cookie is `HttpOnly:
 true`, set in `Service.Set`, and no JS can read it to build the URL.
 
-So anonymous-first is what the current configuration gives, and the honest Path B position is that
+So anonymous-first is what the current configuration gives, and the defensible Path B position is that
 making the document authenticated is a scoped piece of security work with its own cost. Until that
 is costed, budget for anonymous-first: render anonymous, then hydrate the user state over XHR, which
 does carry the header. Anonymous-first is also what a shared cache wants, though see the hydration