refactor: register extension index via exthttp.RegisterRevisionedHandler

[joshiste]

Replaces the hand-rolled startedAt + IfNoneMatchHandler index wiring with exthttp.RegisterRevisionedHandler, so the index ETag is centralized in the SDK and reflects registration state instead of process start.

Bumps extension-kit to v1.11.0 and the SDK kits it uses to the releases that bump the revision on register/clear. Behavior is unchanged for existing agents; the ETag value stays an unquoted string that round-trips as before.

[claude]

Claude finished @joshiste's task in 1m 57s —— View job

---

Claude's Review

• Check previously unresolved review threads for fixes (none found)
• Gather context (diff, dependency source at pinned versions)
• Review code quality, bugs, security, performance, concurrency
• Post final review

This is a clean, well-scoped refactor. Summary of what I verified:

• main.go: Removes the hand-rolled startedAt timestamp + IfNoneMatchHandler wiring in favor of exthttp.RegisterRevisionedHandler("/", getExtensionList). getExtensionList has signature func() ExtensionListResponse, matching RegisterRevisionedHandler[T any](path string, getter func() T) — compiles correctly.
• Ordering is not a concern: I checked that exthttp.Revision() is read live per-request (not captured at registration time), so it doesn't matter that RegisterRevisionedHandler is called after discovery_kit_sdk.Register / action_kit_sdk.RegisterAction in main() — the ETag will reflect whatever has been registered by the time a request comes in, same as before.
• Verified the SDK actually bumps the revision: pulled discovery_kit_sdk v1.4.0 and action_kit_sdk v1.4.0 source — both Register/Clear* functions call exthttp.BumpRevision(), confirming the new ETag will actually change when actions/discoveries are (de)registered, not just at process start.
• ETag format preserved: exthttp.Revision() returns an unquoted string (seed-counter), matching the PR description that the ETag "stays an unquoted string that round-trips as before."
• go.mod/go.sum: straightforward version bumps (extension-kit v1.11.0, action/discovery SDK v1.4.0, plus a few transitive indirect deps) consistent with the go.sum hashes — nothing unusual.

No bugs, security issues, or concurrency problems found. exthttp.BumpRevision() uses atomic.Uint64, so concurrent registration calls are safe.

Note: I was unable to run go build/go vet/make audit in this sandbox (Bash commands required interactive approval that wasn't available in this run), so compilation was verified by manual signature inspection against the pinned dependency source rather than an actual build. Everything lines up, but if you'd like automated verification, allow bash execution for go build/go vet in this workflow's --allowedTools.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud