fix(keyring): clear stale access-token chunks instead of deleting the client secret

[sparkling]

Description

StoreAccessToken's "clear existing chunks" loop deleted the secretClientSecret key on every iteration instead of the indexed secretAccessToken chunks (introduced in #1358). This caused two failures:

1. Stale chunks → corrupted token. Old access-token chunks were never cleared, so re-storing a shorter token left trailing chunks that concatenate into a malformed JWT → authentication token is corrupted.
2. Machine logins couldn't refresh. The client secret was deleted immediately after a machine login stored it, so RegenerateAccessToken → GetClientSecret failed and client-credentials sessions broke at the first token expiry (and never auto-renewed).

The loop now deletes the indexed access-token chunks (matching DeleteSecretsForTenant and the store/get loops) and leaves the client secret untouched.

Fixes #1526

Testing

Added two regression tests in internal/keyring/keyring_test.go:

• overwriting a multi-chunk token with a single-chunk token returns exactly the new token (no stale chunks left over)
• StoreAccessToken does not delete the client secret

Both fail on main and pass with this change. Also verified end-to-end against a live tenant: a machine login followed by a forced token expiry now auto-renews silently instead of erroring with please re-authenticate.

Checklist

• Regression tests added
• go test ./internal/keyring/... passes
• Change is minimal and matches existing patterns in the file

[ramya18101]

Hi @sparkling 👋, This is a great catch!

Thanks for finding this and putting together.
Really appreciate you digging through the old PR and tracking down the root cause here.

Also please sign your commit!