4.9 line: backport candidates from the 5.x line

Stratos 4.9 is the last line that talks to CF through the v2 API; 5.x is
v3-only. Foundations that still serve v2 need 4.9.x patch releases while
5.x moves on, which is exactly the concurrent-line model #5724 builds.
This issue is the work list for the first execution: what from the 5.x
line belongs on release/4.9.x once that branch is cut at v4.9.4.

The inventory below comes from git log v4.9.4..develop -- src/jetstream
(255 commits, ~47 fix-typed) plus a screen of the frontend fix history.
"Verified" means the defective code was confirmed present in the v4.9.4
tree; every port still gets its own diagnosis and test on the branch
before it lands.

Phase 0 — tooling, before any fix

The v4.9.4 tree predates the release machinery entirely: no make
release verbs, no changelog.d/, no release.yml automation. Backport the
machinery to release/4.9.x first so 4.9.5 ships through the same verbs
as 5.x, or accept releasing that line by hand.

Security fixes, defect verified in v4.9.4

• 1c16c17718 kube terminal: InsecureSkipVerify: true is at
  plugins/kubernetes/terminal/start.go:119 in 4.9 verbatim.
• ebc122e3f7 backup encryption key used raw instead of PBKDF2-derived;
  backup_restore.go in 4.9 has the same raw encryptionKey.
• 9bf03dfecc / 043afd4691 session and CF-hosting affinity cookies: no
  Secure: attribute anywhere in 4.9's jetstream.
• 23ee7a59d1 secrets leaking into logs and error messages — same logging
  patterns throughout.
• 7c153acf79 monocular chart-cache path sanitisation (chart store present
  in 4.9).
• 80a7fde85f analysis report path confinement (plugin present in 4.9).
• 72dfe36ab5 cfapppush upload path traversal — upload handling exists;
  the exact site differs, needs diagnosis.
• 590530dd7f unmaintained mholt/archiver/v3 — v3.5.1 sits in 4.9's
  go.mod (indirect); whether the vulnerable path is reachable needs the
  severity pass before porting the replacement.

Correctness fixes, defect verified in v4.9.4

• 5a212d5f2e + 0de3428724 + 6d3370a507 session table name per provider:
  4.9's psql_sessiondata.go hardcodes http_sessions and predates all
  three fixes — PostgreSQL session cleanup is broken there the same way
  it was on 5.x.
• 0c2827941a isSSLRelatedError panic on certificate errors — the
  function is at 4.9's cnsi.go:26 unchanged.
• b6c51e36af / 675290191a token disposal hardening and keeping the stored
  refresh token when UAA omits one — same token repository lineage.
• 916b628f45 last_updated not bumped on token/endpoint updates.

Same defect, different fix shape

• 56622f7f48 fixed Secure on the vendored sqlitestore; 4.9 uses the
  upstream module unvendored, so the same gap closes differently.
• The 401-retry family (06b14436be, a8e26d6d0b, 1fa88f2a0f) fixes the v3
  client; 4.9's v2 paths may share the token-boundary symptom but need
  their own diagnosis.
• Deploy fixes (89c47eb484, de341ba6b8, ee0b8fa361, 6062b23ad9) — deploy
  code exists in 4.9 but diverged; case by case.
• d36f2da842 / db26916744 — need a check whether the defect predates the
  5.x work at all before they qualify.

Frontend: reimplement, not cherry-pick

The rewrite means no frontend fix cherry-picks, but a fix whose defect
predates the rewrite can be reimplemented against the 4.9 UI. Most of
the ~214 frontend fix commits since v4.9.4 fix the rewrite's own code
and are out; these have a verified 4.9 surface:

• 880d1d75a6 strip URL lures from the SSO_Message banner — 4.9's
  login-page.component.ts renders ssoMessage the same way.
• 1639ad5b60 / 42775c9462 honor SSO nosplash for unauthenticated visitors
  and guard the redirect loop — nosplash handling is in the same 4.9
  component.
• 3946c955b1 URL-encode the GitLab repository search term, and the GitLab
  deploy-token handling fixes — 4.9's deploy wizard has GitLab support
  with the same input paths.
• 9a6223995f proto-pollution guard on chart values merge — the 5.x fix
  sits in a 5.x-only editor, but 4.9 has its own deep-merge paths for
  helm values (helm-release-values-tab, reducer.helper.ts); same
  defect class, different site, needs its own diagnosis.

Ruled out

• CSP and security-header work (6780462149 and the rest of the series):
  4.9 sends no CSP at all, so this would be a feature backport — separate
  decision, not on this list.
• cc3f8b63d1 v2-capability probe: it exists to detect v2-disabled CFs;
  4.9's audience is v2-enabled foundations.
• v3-endpoint fixes (9d82c018f1, 2ad3c5fb0e, 5f2af579a5, f404b9967e,
  1d0c7b2ef6): the code they fix does not exist in 4.9.
• a77b2ce84b pure-Go sqlite driver: build modernization, rides the
  Phase 0 tooling decision rather than standing as a fix.
• Frontend fixes internal to the rewrite (strictTemplates, stepper and
  list plumbing, signal-store work): nothing to reimplement, the code
  they fix has no 4.9 counterpart. GitLab private/self-hosted and
  nested-subgroup support (72432c5d29, b1297741c2) are feature backports
  like CSP — separate decision, not on this list.

Dependency CVEs

4.9's go.mod is roughly two years stale. Once Phase 0 lands the 5.x audit
machinery on the branch, drive targeted bumps from a scan of that tree —
CVE-driven only, not currency-chasing on a maintenance line.

Start with #5724 and the v4.9.4 tree, then inspect the release tooling, plugins/kubernetes/terminal/start.go, backup_restore.go, psql_sessiondata.go, cnsi.go, and the named frontend components. First establish the Phase 0 release approach and diagnose each candidate against 4.9 rather than cherry-picking blindly. Done means the branch has usable release machinery and independently tested, justified backports.