fix(security): reject encrypted-envelope credentials at provider create/update validation

[hongkongkiwi]

Closes #15930

What

Rejects provider credentials that arrive already carrying the enc:v1: envelope prefix at both validation seams:

• createProviderSchema (POST /api/providers)
• updateProviderConnectionSchema (PATCH /api/providers/{id})

with a clear message: "apiKey looks like an encrypted envelope from a credential store, not a plaintext key — store the plaintext API key" — instead of today's flow, where the envelope is stored verbatim and surfaces only as a misleading 5ms Missing API key / auth_missing on the connection test.

Why schema-level

encrypt() deliberately skips re-encrypting values that already carry the prefix (src/lib/db/encryption.ts), so the envelope gets stored as-is, then decryptConnectionFields returns null at runtime. Plaintext keys from every provider (sk-…, tvly-…, JWTs, cookie headers, JSON storage state) start with something else, so the rejection is near-zero-false-positive — per the analysis in #15930.

The check is inline in the schemas rather than reusing looksEncrypted(): both schemas are imported by client-side dashboard code (providerOnboardingApi.ts), and the crypto-backed module must not enter that bundle.

Also in this diff

• Drops 10 unused imports in schemas/provider.ts (pre-existing on release/v3.8.52) that trip the pre-commit no-unused-vars gate for any change to this file, plus their now-stale entries in config/quality/eslint-suppressions.json.

Tests

New tests/unit/15930-encrypted-envelope-credential-rejected.test.ts (follows the issue-number naming convention):

• create + update reject an enc:v1:-prefixed credential with an apiKey-path issue
• create still accepts plaintext keys, including values containing enc:v1: mid-string (startsWith semantics)
• update still accepts plaintext keys and unrelated patches; the "No valid fields to update" empty-patch rejection is preserved

Verified locally: 4/4 new + 74/74 existing provider-schema tests pass; eslint-suppressions-pruned consistency test 5/5.

[diegosouzapw]

Thanks @hongkongkiwi — creating or updating a provider now rejects an apiKey that is still an enc:v1: envelope. This is in the upcoming release.