feat(ClineProvider): rebroadcast state on secrets.onDidChange for cross-window consistency

[edelauna]

Related GitHub Issue

Relates to: #11399 (follow-up to #12192)

Description

Stacked on #12192. Until that PR merges, this diff includes all 4 commits. After it merges, only the incremental onDidChange commit will remain in the diff.

When a user stores or deletes the OpenRouter image API key in one VS Code window, other open windows don't receive a state update — so their openRouterImageApiKeyConfigured flag goes stale. This manifests as the API key input showing the wrong placeholder (empty vs. "configured") in windows that didn't initiate the change.

This PR adds a secrets.onDidChange listener in ClineProvider.resolveWebviewView. When VS Code's secrets storage fires a change event for openRouterImageApiKey (which happens whenever any window writes to or deletes the secret), the listener:

1. Calls contextProxy.refreshSecrets() to pull the updated value from the OS keyring into the in-memory cache
2. Calls postStateToWebview() to broadcast the updated openRouterImageApiKeyConfigured boolean

The listener is registered as a webviewDisposable so it is cleaned up automatically when the webview is closed.

Changes are limited to ClineProvider.ts and the test mocks that needed onDidChange added to their context.secrets stub.

Test Procedure

• New integration tests in ClineProvider.spec.ts:
  • Verifies the rebroadcast fires and the updated openRouterImageApiKeyConfigured appears in the payload
  • Verifies unrelated secret key changes do not trigger a rebroadcast
  • Verifies the listener is disposed when the webview closes

Screenshots / Videos

[placeholder — add before/after recording here]

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Documentation Updates

• No documentation updates are required.

Get in Touch