Add generic debugger data providers

[bjdodson-openai]

Description

Adds one bounded provider/settings protocol with strict target identity and truthful unavailable states.

• Uses serialized-document contracts instead of exposing arbitrary provider objects.
• Generation-isolates discovery and actions across target replacement and module reload.
• Bounds request and response envelopes, descriptor access, settings identity, and concurrency.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• Documentation improvement
• Performance optimization
• Test improvement
• Other (new debugger capability)

Testing

• Tests pass locally (bazel test //...)
• Added/updated tests for changes (if applicable)
• Tested on multiple platforms (iOS/Android/Web/macOS as applicable)
• Manual testing performed (describe below)

Testing Details

• Incremental branch: CLI 281/281 and production build passed; focused provider/settings, adversarial bounds, reload, native unload, and browser syntax checks passed.
• Assembled debugger stack: npm test passed 436/436; the CLI production build passed.
• Focused //src/valdi_modules/src/valdi/web_renderer:test passed.
• bazel query //... passed.
• The broad Valdi suite reproduced the established 12 unrelated failures; all new debugger specs passed.

Checklist

• Code follows project style guidelines
• Documentation updated (if needed)
• No breaking changes (or documented in description)
• Commit messages follow conventional format
• No secrets, API keys, or internal URLs included

Related Issues

Relates to #154

Additional Context

Stack 9/22. Stacked on #161 (bjd/debugger-tracing). Review this PR as the single incremental commit 0cc8ec48 against that base; do not merge it before its parent.

[github-actions]

📊 PR Size: size/XL

Total changes: 3529 lines (19 files)

Top files changed:

• src/valdi_modules/src/valdi/valdi_core/src/debugging/DebuggerProvider.ts: +918 -0
• src/valdi_modules/src/valdi/valdi_core/test/DebuggerProvider.spec.ts: +558 -0
• npm_modules/cli/src/debugger/server.spec.ts: +391 -1
• npm_modules/cli/debugger/debugger-providers.js: +325 -0
• npm_modules/cli/src/debugger/server.ts: +249 -19
• npm_modules/cli/src/debugger/browserTools.spec.ts: +217 -0
• npm_modules/cli/debugger/debugger.css: +211 -0
• npm_modules/cli/debugger/debugger-settings.js: +207 -0
• npm_modules/cli/src/utils/daemonClient.ts: +84 -13
• npm_modules/cli/src/utils/daemonClient.spec.ts: +79 -4

...and 9 more files

_{Size calculated as additions + deletions. Labels: XS (<10), S (<50), M (<250), L (<1000), XL (1000+)}

[github-actions]

⚠️ Bazel & CI Test Results

Test Suite	Result
Snapshot Tests	✅ success
API Surface Check	✅ success
Linux: Build & Export	✅ success
Test Coverage Delta	✅ success
Valdi Smoke Tests	✅ success
Linux: Module Tests	✅ success
valdi_web Integration Test	✅ success
Linux: Build Compiler	✅ success
macOS: C++ & Platform Tests	❌ failure
Linux: Hotreload Smoke	✅ success
Linux: C++ Tests	✅ success
Linux: Registry Validation	✅ success

Some tests failed. Please check the workflow logs for details.

🚀 Bazel remote cache is now enabled - future builds will be faster!

_{Workflow: Valdi CI}

[clholgat]

Please carry this feedback into the squashed PR(s).

Also (🟢 Low): debugger-providers.js debuggerProviderForKind() collapses providers to one-per-kind via .find(p => p.kind === kind), while the core contract allows many providers keyed by id (and list returns all, sorted by kind/label). If two providers ever share a kind (e.g. the ClientSQL fork's sql provider alongside another sql-kind provider), only the first by sort order is selectable and the other is silently unreachable in the UI. Worth a per-provider selection surface, or documenting kind as effectively unique in the client.

[clholgat]

🟠 Med — staleness guard rejects valid results on unrelated registry changes. capturedRevision is snapshotted before await provider.handleRequest(request), and any later bump to bridge.revision fails this check and returns {stale:true}. But revision is incremented by any provider's register/dispose/notifyChange(), not just this one — and this provider's own identity is already covered by the provider.disposed / capturedGeneration / capturedToken checks on the surrounding lines.

Failure scenario: a slow Storage snapshot is in flight when a second adapter registers (or an adapter calls the documented notifyChange() on a data change) → the completed, valid snapshot is discarded, the client maps stale → null, and the Data panel renders empty instead of the data.

This is the shared provider contract the ClientSQL fork (#176/#177) builds on, so a fork that registers lazily or fires notifyChange() during live use will hit it.

Suggested fix: drop bridge.revision !== capturedRevision from the condition (rely on disposed/generation/token), or recompute base from the current registry rather than discarding the data.

[bjdodson-openai]

Superseded by #180, which consolidates this patch into the reviewed debugger capabilities landing unit. The replacement carries forward the feedback and fixes discussed here. Closing this draft to reduce the active stack; this PR and its discussion remain the historical review record.