v8.5.36 — sess names no bug, so it comes back out

sess names no bug, so it comes back out

v8.5.35 added sess to the query list because a client redacted it. That was
checked afterwards, which is the wrong order round, and the check came back
empty:

• the client and other CMS sites set session.use_trans_sid = 0; the id rides
  a cookie (session.name = PHPSESSID)
• no ?sess= anywhere across the estate
• the only occurrence in the estate was one client's own denylist, which looks
  copied from a generic list rather than derived from its code

A shared security list should carry rules it can point at a bug for. This one
could not — and addQueryNames(['sess']) is exactly the extension point for an
application that ever does emit one.

What the corpus pins now

The decision, not the rule: ?sess=s-9 survives a scrub, with the reason
beside it, so the next person to consider adding it finds the answer rather
than the question.

Unaffected

Everything else from v8.5.34/35 stands: jwt, bearer and signature on the
substring list, otp, pin and hash query-only. A plain Logger still
covers every other name on the client's two lists, with auth deliberately
query-only (as a substring it eats author) and addresses masked by value with
the domain kept.