Add internal Roslyn analyzers for secret-handling and provider auth safety

[Aaronontheweb]

Problem

We keep re-discovering policy-level mistakes that compile and often pass tests:

• Writing or parsing secret material outside approved secret handlers
• Probing provider configs with only API keys, missing OAuth token fallback
• Descriptor/auth metadata drift (feature advertised but not fully configured)

These are good candidates for static enforcement via internal analyzers (WASDN).

Proposal

Add an internal analyzer package/ruleset for Netclaw that enforces security/config invariants at compile time.

Candidate rules

1. No direct secrets file writes

   • Disallow File.Write* to paths resolving to secrets.json
   • Require SecretsFileWriter / ConfigFileHelper.WriteSecretsFile / approved APIs

2. No raw secret serialization paths

   • Flag direct serialization/writes of secret-bearing values (SensitiveString, provider secret nodes) outside approved handlers

3. Encrypted secret parse must decrypt first

   • Flag parsing of secret JSON string fields when decryption helper/protector is not applied first

4. Provider probe credential fallback

   • For ProviderEntry probe callsites, require credential expression equivalent to ApiKey ?? OAuthAccessToken

5. OAuth capability metadata consistency

   • If descriptor supports AuthMethod.OAuthDevice, require non-null OAuth endpoint/client metadata (or explicit opt-out attribute for TBD providers)

Scope / non-goals

• Not blocking current PRs immediately; can start as warning then ratchet to error
• Keep false positives low with explicit allowlist/attributes for intentional exceptions

Deliverables

• Internal analyzer project + test coverage
• Initial rules (at least Bump dotnet-sdk from 10.0.102 to 10.0.103 #1, Bump Microsoft.Extensions.Hosting from 10.0.2 to 10.0.3 #4, Bump Microsoft.SourceLink.GitHub from 10.0.102 to 10.0.103 #5) with diagnostics + clear fix guidance
• CI integration and .editorconfig severity policy
• Short developer doc: how to comply / when to suppress

Acceptance criteria

• New violations fail CI (after rollout gate)
• Existing codebase either clean or baseline documented
• At least one autofix or code-action where practical

[Aaronontheweb]

This issue is now tracked as a sub-issue under the Roslyn analyzer epic: #304