Drop the redundant force-ssl scope, and reject the playlistItems "fix"

force-ssl is gone from the requested scope. Its grant ("see, edit, and
permanently delete your videos, ratings, comments and captions") is a strict
subset of auth/youtube's ("Manage your YouTube account"), and Google's own
liveBroadcasts.insert reference lists auth/youtube as an accepted ALTERNATIVE
to force-ssl, so every endpoint this app calls — channels, liveBroadcasts,
liveStreams, liveChat, playlistItems — is covered by the one we keep. Two
consent lines became one, and one fewer scope to justify. Removing a scope
cannot narrow capability when the scope being kept is the broader of the two,
and there is no forced re-consent: a refresh token keeps the scopes it was
originally granted, so existing sessions are untouched.

The playlistItems change is NOT being made, and the map entry recommending it
was wrong. It came out of the verification hunt on the theory that public data
should not ride on user credentials. Walking the code kills it: ChannelStats-
Service is built with one HttpClient, and channels?mine=true on the same
service genuinely needs the session. Splitting it means a second unauthenticated
client PLUS a Google API key, since every YouTube Data API request needs a
credential and the call 403s without one. So the fix would ship a new
extractable, quota-abusable credential inside the binary to replace a token the
app already holds, buying zero verification-surface reduction (the data is
public, no scope involved) and zero correctness. Strictly worse. Recorded as a
do-not-do so it is not "helpfully" reintroduced later.

Test: ExactlyOneScopeIsRequested_AndItIsTheBroadOne asserts on the const's
parsed VALUE rather than scanning the file — a file-wide DoesNotContain
fails on the doc comment that names force-ssl to explain its removal, which is
the same trap I hit and documented earlier today in the locator test. Suite
380/380, 0 warnings.

MyMistakes.md

@@ -1314,3 +1314,29 @@ the claim was right but imprecise, and it now says precisely that, with the chec
 The same file was still naming build tag `autobuild-2026-08-09-13-03` — **the tag that 404'd.**
 A licence record that names a stale artifact is worse than no licence record, because it reads as
 verified. When you pin something, the pin and the paperwork must move in the same commit.
+
+### I repeated, in the same session, the mistake I had just written down
+
+The ffmpeg-bundling unit added `TheLocatorCarriesNoNetworkCapability`, which failed on its first
+run because a file-wide `DoesNotContain("Download")` matched that file's own doc comment — the one
+saying "nothing is downloaded". I diagnosed it properly (bare word matches hit prose; use
+call-shaped patterns) and wrote the lesson into this file. **Two hours later, in the very next
+change, I wrote `DoesNotContain("force-ssl")` against `YouTubeAuthService.cs` and it failed for
+the identical reason**: that file now names `force-ssl` in its doc comment *precisely to explain
+why it was removed*. Writing the lesson down did not prevent the repeat; the lesson was not yet
+load-bearing in the place the decision gets made.
+
+**The actual fix, and it generalises past source-scan tests:** don't scan the *file* for a
+token, **extract the value and assert on the value.** A `Regex` that pulls
+`private const string Scope = "([^"]*)";` and then splits the captured string into scopes tests
+the thing that matters — "exactly one scope, and it is the broad one" — and is structurally
+incapable of matching prose. The general form: **when a fact must be asserted about a literal
+that the surrounding documentation is also allowed to discuss, assert on the parsed literal, not
+on the text that contains it.** A test that reads a file and greps it is a test whose failure
+mode is "the comment changed", and that is how source-scan tests get deleted rather than obeyed.
+
+**Meta-lesson worth more than the fix:** I made the same class of error twice inside one session
+while actively documenting it. Repeating a documented mistake is not a knowledge failure — the
+knowledge was fine — it is a *check* failure. The check that would have caught it: when a
+`DoesNotContain` is aimed at a file, ask "does this file's own documentation have a legitimate
+reason to contain the string?" If yes, the assertion is aimed at the wrong target.