fix(MyAnonaMouse): persist refreshed mam_id so sessions don't expire after 30 days

[director-mouse]

My MAM indexer has been losing auth on the 1st of every month for a while now, and after pulling the logs it turned out to be exactly 30 days after each session was created, to within the granularity of the hourly MyAnonaMouseAccountStatusService refresh. Two consecutive cycles lined up: a session created 2026-07-02 ~03:00 UTC died 2026-08-01 between 02:51 and 03:03 UTC, and the replacement created 2026-08-02 ~03:03 UTC died 2026-09-01 between 02:32 and 02:56 UTC. In both cases MAM started answering 403 with Error, you are not signed in on both jsonLoad.php?snatch_summary and loadSearchJSONbasic.php, with no network changes on my side.

MAM rotates the mam_id cookie via Set-Cookie, and the comment above the StoreResponseCookie lines in MyAnonaMouse.cs says the intent is to keep the "updated mam_id from MAM". The code never manages that, though. Every request sets request.Cookies["mam_id"] = Settings.MamId, and InitializeRequestCookies in HttpClient.cs lets request.Cookies overwrite whatever the persistent container holds (and with StoreRequestCookie = true it writes the stale value back into the container as well). So Chaptarr only ever presents the original cookie, and the original cookie has an absolute expiry of roughly 30 days.

This PR fixes that in the one place that already has the right plumbing. RefreshAccountStatus() runs hourly and MyAnonaMouseAccountStatusService already calls _indexerFactory.Update(definition) right after it to persist UserClass, IsVip and the unsatisfied counters. If the response carries a mam_id that differs from Settings.MamId, we write it into Settings.MamId and the existing persistence call saves it. Nothing else changes: the search and download paths keep overriding the jar with Settings.MamId, which is fine once that value is kept current, and the up-to-one-hour lag between MAM rotating and Chaptarr persisting is a non-issue given the old cookie stays valid for a month.

One thing worth knowing is that this only does anything while the status refresh succeeds. Because ProviderFactory reloads definitions from the DB on every call, a rotated mam_id written into Settings is thrown away if RefreshAccountStatus() throws before _indexerFactory.Update(definition) runs, and Chaptarr keeps presenting the last one that was saved. That's what happened between MAM's snatch_summary response change on 2026-09-23 and #189 (#189), which is in v0.9.965, so this PR has no other dependencies now.

A couple of things I'm not 100% sure about and would appreciate a second pair of eyes on:

1. MAM rotates mam_id on every jsonLoad.php?snatch_summary response as far as I can tell, with Max-Age=1296000 (15 days) on the new cookie, and older values keep working after newer ones are issued. I don't know whether that's guaranteed behavior on MAM's side or just what it happens to do today.
2. TestConnection() calls RefreshAccountStatus() on a throwaway definition, so a rotated value there won't be persisted, which I think is the correct behavior but worth calling out.

I've been running this patch since 2026-09-07 05:25 UTC, on a fresh session created at the same time (on v0.9.958 plus #189, and now on v0.9.965). That session's old 30 day mark was 2026-10-07 05:25 UTC, and it went straight past it with no 403s, with MAM issued a refreshed mam_id and Updated MAM account status logged on every hourly refresh. The patch applies cleanly to v0.9.965.

I've also added regression tests to MyAnonaMouseWedgeFixture: a rotated mam_id is sent on the next status request and saved by the refresh service, a missing or blank cookie keeps the current value, and a failed refresh (HTTP error or invalid summary) saves nothing. The two rotation tests fail without the fix. dotnet test src/Chaptarr.Core.Test/Chaptarr.Core.Test.csproj passes (3,043 tests), though locally I had to add -p:WarningsNotAsErrors=NU1902%3BNU1903 because restore currently fails on the existing SixLabors.ImageSharp 3.1.12 vulnerability warnings.