auto-release-327

Make CSRF token handling resilient to badtoken errors (#111)

* feat: retry MediaWiki/Wikidata mutating calls on badtoken

CSRF tokens fetched before mutating calls were never refreshed if
MediaWiki rejected them as invalid, failing the whole operation
(including mid-way through a chunked upload). Add a one-shot
fetch-fresh-token-and-retry helper to MediaWikiClient (for both
apiRequest-based and FormData-based chunk/commit calls) and an
analogous pair of private methods to WikidataClient, and wire every
mutating call site through it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017ak8tpbsoWNcVsSAhxBygf

* test: dedupe badtoken retry tests merged into existing describe blocks

The previous commit added new describe blocks for createPage/applySdc/
replaceCategoryInPage/nullEdit without noticing equivalent blocks already
existed later in the file, creating duplicates. Merge the new badtoken-retry
tests into the pre-existing blocks instead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017ak8tpbsoWNcVsSAhxBygf

* refactor: unify badtoken retry logic into one shared helper

MediaWikiClient had two near-identical private retry methods
(apiRequestWithTokenRetry, apiUploadChunkWithTokenRetry) and WikidataClient
had a third (editItemWithTokenRetry), all implementing the same
fetch/reuse-token -> request -> refetch-and-retry-once-on-badtoken algorithm,
differing only in how the underlying request was made. Extract this into a
single withCsrfTokenRetry(label, getToken, doRequest, token?) function shared
by both clients, and log a warning (with a per-call-site label, e.g.
"[mw] uploadFile chunk 2/3") whenever a retry is triggered so a badtoken event
is visible in logs instead of silent.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017ak8tpbsoWNcVsSAhxBygf

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>