Close the subscription list's offline write hole, and stop four catch blocks hiding defects

[rghvgrv]

Three review findings from a full-repo pass, all in the mobile client. #155 from the same pass is already in via #156 and is not touched here.

Closes #152 — the list screen's offline write hole

The subscription list was the one write-capable screen with no offline guard, and it is the one most likely to be open without a network — it serves itself from the SQLite mirror and says so ("Offline — showing last synced data"). Two writes sat on it unguarded:

• swipe-to-delete
• "Mark as paid"

Both stayed enabled with no network, and both reported the resulting lost write with read wording — "You appear to be offline." — which reads as "we'll sync it". There is no outbox (#144), so the write was simply gone.

Mark-paid is the worse of the two. The row keeps its OVERDUE chip whether the call landed or not, so nothing on screen contradicts the misreading — the user believes they cleared a charge that is still outstanding.

It now follows the contract the other four write-capable view models already share:

	before	after
IConnectivityService	not injected	injected
IsOffline	—	re-read on load and after a failed write
CanSubmit	—	gates both affordances via IsEnabled in XAML
failed-write message	ToDisplayMessage	ToWriteFailureMessage

IsBusy is new here rather than reused from IsLoading, which drives the pull-to-refresh spinner. Mark-paid is not idempotent — it advances the billing date one cycle per call — so a double tap would settle two periods off one payment.

Closes #153 — four catch blocks laundering defects into offline errors

ApiErrorMapper.IsApiFailure exists to be a catch filter; 21 of 25 blocks used it, four did not. The two load paths were the dangerous ones: they fall back to cache, so a defect of ours (a null in RebuildGroups, a bad cache round trip, a converter throwing) showed stale rows under "showing last synced data" on a phone that was perfectly online, with nothing logged. That is the hardest class of bug to get a report about, because it looks like it is working as designed.

All four now filter. SubscriptionDetailViewModel:253 is left alone — its broad catch is documented as intentional and nothing falls back to cache there.

Closes #154 — comments describing a job that no longer exists

RelativeDate.cs told the reader a past billing date "means the app is looking at stale data" because "the server's billing-date job rolls them forward". That job was deliberately removed; a past date is the intended overdue signal and is what SubscriptionDto.IsOverdue reads. The comment invited exactly the change CLAUDE.md forbids. Same drift in RenewalNotificationPlanner.cs.

Verification

dotnet test tests/SubVora.Mobile.Tests      → 264 passed, 0 failed
dotnet test tests/SubVora.Application.Tests →  38 passed, 0 failed
dotnet build src/SubVora.Api                → 0 warnings, 0 errors

Test coverage added, since the absence of it is why #152 went unnoticed:

• OfflineWriteGuardTests now includes the list in both CanSubmit assertions, plus a failed mark-paid, a failed swipe-delete, and the drop-mid-session case
• SubscriptionListViewModelTests / DashboardViewModelTests assert a defect propagates instead of turning into a cache fallback

No API, schema or contract changes.