feat: show the metadata version in use #404

Summary

Surface the @openscan/metadata version the app is actually consuming, so it can be read
off the screen instead of inferred from the source.

Motivation

METADATA_VERSION is a hardcoded constant in
src/services/MetadataService.ts:10
that pins every metadata fetch to one jsDelivr URL:

export const METADATA_VERSION = "1.2.1-alpha.0";
const METADATA_BASE_URL = `https://cdn.jsdelivr.net/npm/@openscan/metadata@${METADATA_VERSION}/dist`;

Nothing in the UI reveals that value, which bites in three places:

1. Stale metadata is invisible. explorer-metadata ships new networks, tokens, RPC
   endpoints and logos on its own cadence — Zcash lands in
   feat: add zcash mainnet and testnet explorer-metadata#17 as 1.3.0-alpha.0, while the explorer is pinned
   to 1.2.1-alpha.0. Until the constant moves, the app looks exactly the same as if the
   data were current. There is no way to tell from the running app which metadata build is
   behind what you are looking at.
2. The version keys the RPC cache. src/utils/rpcStorage.ts:114,127 stores it with the
   cached endpoints and discards the cache when cache.version !== METADATA_VERSION. When
   a user reports "my RPC list didn't refresh", this is the first thing worth knowing, and
   right now it can only be recovered by reading the bundle.
3. Bug reports don't carry it. The footer's report-a-bug link ships the app version and
   commit hash; a metadata-driven bug (missing token logo, wrong network entry) is not
   reproducible without also knowing the metadata version.

Proposed Solution

1. Footer — the version at a glance. src/components/common/Footer.tsx already renders
t("footer.versionLabel", { version: appVersion, hash: formattedCommitHash }), linking to
the commit. Extend it with the metadata version:

v1.2.6-alpha  1a21a35  ·  meta 1.2.1-alpha.0

The string lives at footer.versionLabel in src/locales/{en,es,ja,pt-BR,zh}/common.json
(line 47) — either extend that key with a {{metadataVersion}} placeholder or add a
sibling key, in all five locales.

2. Settings → Advanced — the detail. The cacheData section in
src/components/pages/settings/index.tsx (~line 1660) is where cache clearing already
lives, so it is the natural home for a read-only metadata info block: version, build time,
entity counts, and the jsDelivr base URL as an openable link.

That data is already published and currently unused by the explorer —
@openscan/metadata writes dist/manifest.json in its build:

{
  "version": "1.2.1-alpha.0",
  "buildTime": "2026-04-21T13:02:01.396Z",
  "counts": { "tokens": 414, "networks": 19, "rpcs": 230, "apps": 1, "organizations": 2,
              "supporters": 7, "donations": 0, "events": 23, "addresses": 1 }
}

Nothing in src/ fetches manifest.json today. Add a getMetadataManifest() to
MetadataService, following the same shape as the existing rpcs/all.json fetch, and
cache it like the other metadata responses. Showing buildTime alongside the pinned
version also distinguishes "we're on an old version" from "the CDN served us a stale copy".

3. Optional — drift hint. Compare the pinned version against the published dist-tag and
show a subtle "newer metadata available" note. If this is implemented, be careful which tag
it queries: the tags are currently split —

latest -> 1.0.1
alpha  -> 1.2.1-alpha.0

so a naive check against latest would report a downgrade.

Acceptance Criteria

• The metadata version is visible in the footer next to the app version and commit hash
• Settings → Advanced shows the metadata version, build time and entity counts, read
  from dist/manifest.json
• MetadataService exposes a getMetadataManifest() helper, cached like its siblings
• The base jsDelivr URL is shown (or linked) so the exact source can be opened
• New/changed strings added for all five locales (en, es, ja, pt-BR, zh)
• The UI degrades gracefully when manifest.json cannot be fetched — the pinned
  constant still renders, since it is known without a network call