feat(settings): show what version the server is running

[SiteRelEnby]

Why

Three features now degrade on older servers and have to say so: public profiles, group and custom-field reordering, and shortly the group and tag filters for tile scoping, which need the bulk membership reads landing in server 1.5.1. "This server doesn't support it yet" is only actionable next to "and here's what you're running" - especially for the many people whose server is run by somebody else and who need to know what to ask for.

What

/v1/version has never been called by the app. It is now fetched once per instance and shown under Settings > Server, alongside the API URL.

• Cached against the base URL, so switching instances can't leave the previous server's version on screen.
• Failures aren't cached; being offline once shouldn't mean the version stays unknown until the app restarts.
• The endpoint is unauthenticated, so this works before login too if we ever want it there.

The rule these helpers follow

Version is for wording. Detection decides behaviour. Whether a feature is used stays decided by asking for it and seeing what comes back - a 404, a 405, a field that is absent - because that's the only thing that survives a self-hoster running a build off main, a fork, or a version string nobody anticipated.

Falling out of that:

• An unreadable version is unknown, never "too old". A feature that works must not be withdrawn over a version string we failed to parse.
• A release candidate counts as having the code it's a candidate for. Telling somebody on 1.5.1-rc1 to upgrade to 1.5.1 for a feature they already have is the worse error.
• A git tag beats the package version, since a build made from a tag knows what it is more precisely than its metadata does.

Ten unit tests cover the parsing and those rules.

Drive-by fix: ShareExpiryTest

Failing on main before this branch existed, and it would fail or pass on CI depending on the runner's JDK.

EXPIRY_FORMAT is ofPattern("d MMM yyyy") with no locale - correct, since the date on screen should follow the device - but the test asserted "Expired 1 Sep 2026" by hand. Recent CLDR data abbreviates September in en-GB as "Sept", so:

expected:<Expired 1 Sep[] 2026> but was:<Expired 1 Sep[t] 2026>

The expectation is now built with the same formatter, so the test checks that the expiry date is shown rather than pinning CLDR's opinion of what September is called.