Fix version race in the image build, and add image/service tests

[marvinm2]

The problem

The image published as 3.0.31-2.1.9 contains the 2.1.8 webservice JAR.

The docker job took the webservice version from the setup.sh in its own checkout. actions/checkout resolves the SHA that triggered the run, which predates the commit update-version makes — so the image tag came from a freshly downloaded pom.xml (correctly 2.1.9) while the JAR came from the stale checked-out setup.sh (still 2.1.8). Nothing detected it, because each half was internally consistent.

This is structural rather than a one-off: every run bakes the previous release's JAR while labelling it with the current version.

Verified against the published image:

$ tests/verify-image.sh bigcatum/bridgedb:3.0.31-2.1.9
  FAIL  setup.sh in image pins "2.1.8" but the tag says "2.1.9"
  FAIL  /swagger.yaml reports '2.1.8' but the image is tagged for '2.1.9'

Separately, :latest was built by a second, independent build-push-action invocation, so it was never the same image as the version tag — its digest matched the 2.1.7 image.

The fix

• A new resolve-version job reads the pom once and passes bdbversion/wsversion to the other jobs as outputs, so they cannot disagree.
• The docker job pins setup.sh in its own workspace from that value and fails if the pin does not take. The build no longer depends on a commit made by a concurrent job.
• resolve-version fails fast when the webservice release JAR is not yet published, instead of dying part-way through an hour-long build.
• :latest is no longer built separately. test-and-promote pulls and verifies the published version tag, then re-tags that exact digest as :latest, and asserts both tags share a digest. A mislabelled or broken build can no longer become :latest.
• update-version still commits setup.sh back to main, but that commit is now bookkeeping rather than something the build reads.

The tests

tests/smoke-test.sh exercises a running service; tests/verify-image.sh wraps it, first checking what is baked into an image (pinned version, valid JAR, present gdb.config) and then starting the container and running the smoke tests. Both are plain shell and runnable locally:

tests/verify-image.sh bigcatum/bridgedb:3.0.31-2.1.9
tests/smoke-test.sh http://localhost:8183 2.1.9

Coverage: the version the service reports for itself, the organism and datasource catalogues, Derby-backed human and mouse mappings, the attributes endpoint, and target-restricted mapping.

verify-published-image.yml runs the same verification weekly, and on demand for any tag, against whatever is on Docker Hub.

Two things worth knowing about these tests

Assertions are on response bodies, not status codes. The webservice returns HTTP 200 for unknown paths with an "Unrecognized query" page rather than a 404, so a status-code assertion passes even against a server that resolves nothing at all.

/swagger.yaml is the only endpoint reporting the running JAR's version, which makes it the single check capable of catching an image tagged for a release it does not contain.

Note on merging

Merging does not by itself correct Docker Hub — 3.0.31-2.1.9 and latest both still carry 2.1.8 code. The build needs re-running after this lands, which will republish the version tag correctly and promote latest to it once the tests pass.

The pat_external_workflow secret in bridgedb/BridgeDbWebservice is still invalid (Bad credentials), so releases will continue to fail to trigger this workflow until it is regenerated. That is outside this repo.