Make CSRF token handling resilient to badtoken errors

[DaxServer]

MediaWiki API tokens can occasionally be rejected as invalid (error.code === 'badtoken'), and every mutating call in MediaWikiClient / WikidataClient previously failed outright when that happened — including mid-way through a chunked upload, discarding chunks already staged on the server.

• Add a shared withCsrfTokenRetry helper: fetch/reuse a token, make the request, and on badtoken fetch a fresh token and retry exactly once.
• Wire it into every mutating call site: createPage, applySdc, replaceCategoryInPage, nullEdit, both loops in uploadFile, and WikidataClient.editItem.
• Fix a latent gap in nullEdit and editItem: neither previously inspected the API response body for an error field, so a badtoken failure was silently swallowed as success.
• Log a warning with a per-call-site label (e.g. [mw] uploadFile chunk 2/3) whenever a retry actually fires.

[greptile-apps]

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
backend/src/mediawiki/tokenRetry.ts	Adds the shared CSRF retry helper that retries once on badtoken and returns the final result and token.
backend/src/mediawiki/client.ts	Uses the shared retry helper across MediaWiki mutating calls and preserves upload token propagation.
backend/src/mediawiki/wikidata.ts	Uses the shared retry helper for Wikidata edits while keeping the same request body and signing inputs.
backend/src/tests/tokenRetry.test.ts	Adds direct tests for retry success, retry exhaustion, token reuse, and first-attempt success.
backend/src/tests/uploadClient.test.ts	Adds MediaWiki mutation and upload tests for badtoken retry behavior.
backend/src/tests/wikidataClient.test.ts	Adds Wikidata edit tests for retry success and retry exhaustion.

_{Reviews (1): Last reviewed commit: "refactor: unify badtoken retry logic int..." | Re-trigger Greptile}