Restore the .gitmodules branch pin so Renovate tracks testbed versions again #1852

#1778 dropped the branch = v3.5.0 pin from both test-harness submodules in .gitmodules. It reads as harmless — the exact SHA is still pinned — but it is the line Renovate uses to track testbed versions, and testbed updates here have been dead ever since.

This repo is also the clearest case of the consequence. Two submodules point at the same testbed repo and used to be bumped in lockstep; they have since drifted:

Two versions of the same conformance suite in one build. Every bump since the removal has been manual — #1817 is literally titled chore(flagd): bump test-harness submodules to v3.8.0 — and a digest update is sitting unactioned on the dependency dashboard in #143.

Note the PR restores each submodule to the tag it points at today, so it records the drift rather than fixing it. Realigning the two is a separate decision.

Why this matters

Renovate's git-submodules manager reads branch from .gitmodules as the dependency's current version. With the pin present it resolves against the testbed's release tags and opens an ordinary version bump, rewriting the pin itself:

-	branch = v2.10.1
+	branch = v2.10.2

Without it there is no version to compare against, so Renovate falls back to chasing the tip of the testbed default branch — a digest update. Those don't match the community-tooling preset's matchSourceUrls auto-create exemption, so they get parked behind a dashboard checkbox instead of becoming PRs. Net effect: no automated testbed updates in this repo since the removal.

The fix

The attached PR restores branch = <tag> on the testbed submodule, set to the tag it currently points at. That is the whole fix — no Renovate config change is needed, because the preset's existing exemption starts matching again as soon as the dependency resolves to a version.

Parent: open-feature/flagd-testbed#398