fix: a credential, an erased account and a stale level stay out of the log

Round 2 of the E22 review, on what round 1 changed.

`redact_query` decodes a parameter before the text rules see it, which is what lets `%40` be
recognised as an address — but `_SECRET_PARAM_RE` was written for the raw, encoded form, where a
value holds no space, `&` or quote. On decoded text its value class stops at the first one, so
`?state=a%20b` kept its tail and `?code=%20abc` was not matched at all. The parameter-NAME rule now
decides, on the key, before any text rule runs.

`forget_user` dropped the account's level elevation without recomputing the root level, so a process
whose only elevated account had just deleted itself kept building TRACE records to throw away, until
some later request happened to recompute it. Every other path that drops an elevation recomputes.

The sink's writer took the erasure lock and THEN waited for a pooled connection, while every request
path already holds a connection when it reaches that lock — so under pool pressure the writer held a
process-global lock against the very requests that could hand a connection back. Same order on both
sides now; the lock still spans the check, the insert and the commit.

The storage-budget notice said the rest of the hour was not kept, and then smaller batches kept
landing underneath it: the window slides and a refused batch is not charged to it. Says what it does.

Tests: the route's half of the erasure rule had no test — only the sink's did — and a source-level
contract test now covers the third insert nobody has written yet. `logs._erased` is process-global
with an hour's memory while the DB fixture hands serial ids back out from 1, so it is swept before
each test like the rate limiters are.

backend/tests/conftest.py

@@ -214,3 +214,15 @@ def _reset_rate_limiters():
         for obj in vars(mod).values():
             if isinstance(obj, RateLimiter):
                 obj.reset()
+
+
+@pytest.fixture(autouse=True)
+def _reset_log_erasures():
+    """`logs._erased` is module-level and remembers an erased account for an hour of monotonic time
+    — longer than any suite run — while the `db` fixture hands serial ids back out from 1 via
+    TRUNCATE … RESTART IDENTITY. So a test that purges user 1 would otherwise make a LATER test's
+    rows for user 1 store with `user_id = None`, failing somewhere nowhere near the cause and only
+    in some file orders. Same reasoning as the limiter sweep above, different global."""
+    from app import logs
+
+    logs._erased.clear()