ci: disable the testcontainers reaper on the conformance job

[juicycleff]

Store Conformance (pg + mongo) went red on #110 for a reason that had nothing to do with #110. Both postgres suites died at the line that starts the container:

run postgres: generic container: create container: reaper:
wait for reaper 50cef248: context deadline exceeded

That is the testcontainers reaper, the container it starts to clean up after a test process that dies without terminating its own containers. It failed to come up inside its 60 second deadline, so oauth2provider and sso both reported red before a line of authsome code ran. It will keep doing that on unrelated PRs, because it fails before the thing under test is reached.

Why turning it off is safe here

What the reaper insures against cannot happen on this job. Every one of the 11 container starts in the tree pairs 1:1 with an explicit Terminate in t.Cleanup, and this runner is destroyed when the job ends, so a leaked container has nowhere to leak to.

The variable is set on the single step that runs -tags integration, which is the only place in CI that starts a container at all. Nothing sets it locally, so go test -tags integration on your machine still gets the reaper, which is where the guard is actually worth having.

Verified

Ran the two suites that failed, with the reaper off:

--- PASS: TestConformance/Memory   (0.00s)
--- PASS: TestConformance/SQLite   (1.49s)
--- PASS: TestConformance/Postgres (1.46s)
--- SKIP: TestConformance/Mongo    (0.00s)   no AUTHSOME_MONGO_URI locally, CI supplies it

docker events confirms real postgres:16-alpine containers were created, so postgres is genuinely exercised rather than skipped. The container count on the host is identical before and after, which is the cleanup the reaper would otherwise be insuring.

One thing this is not: a speedup. The reaper costs about half a second per package, so roughly five seconds across the job. The point is that it stops failing runs for reasons unrelated to the code under test.