Issue #3594323: Stop the WebDAV auth-token credential leaking into the audit row

Fixes #3594323.

Root cause. WebDavEventContributor removed the request_uri key from the webdav event context, but AuditTrail::event() forensic-stamps request_uri with the Drupal request URI via the += operator (which fills only absent keys). The removed key was re-populated with the same URL-token path on a URL-token-authenticated request, landing the token in context_transient.

Impact (scoped). The leaked value is a per-file WebDAV token (HMAC over fid / filename / revocation-version), not an account credential, and it is bound to the user's session: the per-user master secret is revoked on logout and expires with session.gc_maxlifetime. A reader of the audit log could therefore, only within the victim's session window, reach the specific file(s) whose tokens passed through the log -- not the account, and not files the user never touched. Narrow and time-boxed, but it still contradicts the module's stated guarantee that the audit row carries no working-credential trace, and a forensic log is read by auditors who should not receive even a scoped credential.

Fix. Blank request_uri (set empty) instead of removing it, so the += no-ops and the token never reaches the row. The resource column already records the path without the credential.

Test. New kernel test pushes a real token-bearing request onto the stack (the existing strip test ran with an empty stack and could not catch this). Verified it fails before the fix and passes after. Full suite: 13 tests green; phpcs clean.

Also bundled (same audit). README drift corrected: the chain claims the audit_trail_webdav channel (not webdav) in mode: flag (not auto), edit path /admin/config/system/audit-trail/chains/audit_trail_webdav/edit.