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 2m 48s —— View job

---

Claude's PR Review

• Check for previously unresolved review threads authored by Claude (none found on this PR)
• Review new changes (main.go, go.mod, go.sum)
• Post findings

Summary: This is a clean, small refactor. main.go drops the hand-rolled startedAt timestamp + IfNoneMatchHandler wiring in favor of exthttp.RegisterRevisionedHandler("/", getExtensionList), and go.mod/go.sum bump extension-kit to v1.11.0 and action_kit_sdk to v1.4.0.

I verified the new SDK behavior directly against the tagged sources:

• extension-kit@v1.11.0's exthttp.Revision() reads a sync/atomic counter that's bumped by BumpRevision() — safe for concurrent access, and RegisterRevisionedHandler evaluates Revision() per-request rather than snapshotting it at registration time. This means the fact that action_kit_sdk.RegisterAction(...) (main.go:54) runs before exthttp.RegisterRevisionedHandler(...) (main.go:56) has no correctness impact — the ETag will reflect all registrations that happened before the server starts serving traffic either way.
• action_kit_sdk@v1.4.0's RegisterAction/ClearRegisteredActions call exthttp.BumpRevision() as described in the PR body, confirming the ETag now reflects registration state rather than process start time.
• The ETag remains an unquoted plain string (revisionSeed + "-" + counter), so it round-trips through If-None-Match exactly as the old startedAt value did — no behavior change for existing agents.

No bugs, race conditions, or security concerns found in this diff. No unresolved prior review threads exist on this PR to reconcile.

[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