Build the backward-compatibility baseline from the latest release instead of main

Problem

The CIT Backward Compatibility workflow (.github/workflows/ci-backward-compatibility.yml) builds the "earlier" Jaeger from ref: main:

    - name: Check out the earlier revision
      uses: actions/checkout@...
      with:
        ref: main
        path: .jaeger-old

The workflow's own header describes the check as catching a change "that leaves the pull request unable to read what the released binary wrote", but no released binary is involved. What the job verifies is that a pull request can read what current trunk wrote. That only catches breakage introduced by the one PR relative to trunk, and it says nothing about the compatibility promise users actually rely on, which is release to release: a deployment running the latest release upgrades to the next one and must still read its existing data.

Because trunk moves with every merge, a schema change that lands on main in one PR is "old" for every later PR, so a compat run that is green against main can still be red against the last release.

Proposal

Build the earlier revision from the latest release tag rather than from main. The repository already resolves that tag: scripts/utils/compute-version.sh prints the closest v2.* tag and is what BuildInfo.mk bakes into the binary as its version. The workflow can run it against the pull-request checkout and pass the result as ref: for the .jaeger-old checkout. The script returns 0.0.0 on a shallow clone, so that checkout step needs fetch-depth: 0 (or fetch-tags: true) for the tags to be present. JAEGER_OLD_CONFIG_DIR keeps pointing at the old checkout's cmd/jaeger, so the earlier binary still runs the configuration files from its own revision.

Keeping main as a second matrix axis is cheap and gives a finer signal when a PR breaks something that landed on trunk since the last release, but the release comparison is the one that must pass.

Related follow-up (separate discussion, tracked elsewhere): the harness currently runs the earlier binary with no feature gates, which conflates several upgrade scenarios; the fix for that is independent of which revision the earlier binary is built from.

Related

• #8691 requested the backward-compatibility integration tests.
• #9437 added the workflow and the harness, with main as the earlier revision.
• #9441 extended the suites to Cassandra and ClickHouse.
• #9321 is where the gap surfaced: its typed-attribute mapping is tested against the earlier binary as built from main, so the result changes meaning the moment the PR merges.