feat(preflight_kit_sdk): bump index revision on register/clear

[joshiste]

What

RegisterPreflight and ClearRegisteredPreflights now call exthttp.BumpRevision() so the extension index ETag reflects the set of registered preflights.

Why

Part of centralizing index-response caching in the SDKs (see steadybit/extension-kit#158). The index ETag becomes registration-scoped instead of frozen at process start.

Depends on

steadybit/extension-kit#158 — exthttp.BumpRevision is introduced there. CI on this PR is red until extension-kit is tagged; I'll bump go.mod/go.sum to the new tag as a follow-up commit.

[claude]

Claude finished @joshiste's task in 2m 25s —— View job

---

Claude finished reviewing this PR

• Check for previously unresolved Claude review threads — none found
• Gather context (diff, extension-kit BumpRevision/Revision implementation, CI status)
• Review new changes for bugs, security, performance, concurrency issues
• Post findings

Review

The diff is small and does exactly what the PR description says:

• go/preflight_kit_sdk/preflight_sdk.go:179 — RegisterPreflight calls exthttp.BumpRevision() after registering the handlers.
• go/preflight_kit_sdk/preflight_sdk.go:185 — ClearRegisteredPreflights calls it after resetting the map.
• go/preflight_kit_sdk/revision_test.go — new tests assert the revision changes after each call.

I checked the actual extension-kit implementation (steadybit/extension-kit#158, now vendored at v1.11.0 per this PR's go.mod/go.sum):

var revisionCounter atomic.Uint64
func Revision() string { return revisionSeed + "-" + strconv.FormatUint(revisionCounter.Load(), 10) }
func BumpRevision()    { revisionCounter.Add(1) }

BumpRevision/Revision use an atomic.Uint64, so:

• Calls are safe to make concurrently — no race introduced by adding them here.
• The counter monotonically increases, so the new tests (before := exthttp.Revision(); ...; assert.NotEqual(...)) can't be flaky — every bump is guaranteed to produce a different value.

No bugs, security issues, or concurrency problems found in the new code. The two call sites are the only two places in this file that mutate registeredPreflights, so revision bumping is complete/consistent for this SDK. (The pre-existing lack of a mutex around the registeredPreflights map itself is unchanged by this PR, so I'm not flagging it here.)

One note rather than a blocker: the PR description says CI would be red until extension-kit is tagged and a follow-up go.mod/go.sum bump was needed — that follow-up (chore(deps): bump extension-kit to v1.11.0) is already included in this PR's HEAD, so the dependency should resolve correctly. CI was still in progress at the time of this review with no failures reported so far.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud