Move to the next Metabase LTS line when one is designated

[jamalk23]

User story / feature request

As an ADSD staff member operating Metabase,
I want the instance to track Metabase's designated Long Term Support release line,
so that we keep receiving security patches on a predictable cadence and are never forced into an unplanned major upgrade because our line went end-of-life.

Metabase designates one release line at a time as LTS and supports it for longer than
ordinary lines. Production and staging currently run the v0.58 line, which is
today's LTS (v0.58-lts is the only LTS tag published on either the OSS or Enterprise
image repo at time of writing).

So this ticket is not remediation — it is a standing commitment to move to the next LTS
line deliberately, once Metabase names one, rather than discovering later that 58 has
stopped receiving patches.

Acceptance Criteria

The next LTS line has not been designated yet. This ticket stays open until it is,
then:

• The newly designated LTS version is identified and recorded here, with a link to
  Metabase's announcement.
• The upgrade is rehearsed against a copy of production data using
  runbooks/workflow/metabase-test-instance-from-prod.md, and the migration
  completes successfully. This is required — unlike the same-line patch bumps
  we have been doing, a major-version jump changes enough schema that staging (a
  small test environment, not a prod snapshot) is not sufficient validation.
• Staging runs the new LTS version and is verified: dashboards render, a
  BigQuery-backed question returns rows, permissions behave correctly for a
  non-admin.
• Production runs the new LTS version, verified the same way.
• runbooks/workflow/upgrade-metabase.md is updated with measured migration
  timings from the jump, and the startup probe budget in both service.tf files is
  confirmed sufficient for the larger migration.

Notes

Current state. Both environments are on the v0.58 line. Patch-level currency within
that line is tracked separately — the line is already ahead of what we run, and keeping
up with it is ordinary maintenance, not this ticket.

A major jump is not a patch bump. Every Metabase upgrade we have done so far has
stayed inside v0.58, where migrations are small and quick (65–80s observed). Crossing
to a new major line means substantially more schema migration, so it needs the prod-data
rehearsal, a wider startup probe budget if the rehearsal shows one is needed, and a
planned window rather than an opportunistic deploy.

Enterprise procurement interacts with this. Enterprise is being procured separately.
EE ships as v1.x.y from a different image repo (metabase/metabase-enterprise) with
matching minor/patch numbers, and it has its own LTS designation that tracks the OSS one
(v1.58-lts today). If both the EE cutover and an LTS jump are pending at the same time,
they should be sequenced deliberately — doing them together means two large changes
landing in one migration, with no way to tell which caused a problem.

Do not pin to the floating -lts tag. It moves on its own, which would let the
running version change with no pull request and no record in git. Pin the exact patch
version and let the bump be a reviewed change.

Process. runbooks/workflow/upgrade-metabase.md covers the mechanics end to end,
including the rollback paths and the Liquibase lock case.

Related: #4928 (formalize cloud-run Metabase updates).