Encrypt ExternalFeed.Password at rest

Summary

• Encrypt the ExternalFeed.Password column (package-feed credential, previously cleartext) at rest in ExternalFeedDataProvider — the single seam every feed read/write funnels through (deploy-pipeline package fetch, Helm/K8s registry auth, the feed service), reusing the IVariableEncryptionService V2 envelope. Same proven pattern as DeploymentAccount.Credentials (#437).
• Decrypt-on-read uses repository.QueryNoTracking (detached entities) so the in-place decrypt can never be flushed back as plaintext by a later shared-scope SaveChanges — the flush-back hazard caught & fixed in #437, applied here from the start.
• Non-breaking / zero migration: read-both via the SQUID_ENCRYPTED_V2: prefix (unprefixed values returned verbatim → pre-existing plaintext rows still load, upgrade lazily). Encrypt-on-write is idempotent. No service-layer change — ExternalFeedDto exposes only PasswordHasValue (a non-empty ciphertext still reports true), so the response stays correct with the entity holding ciphertext.
• Reuses the existing Security:VariableEncryption:MasterKey — no new key source, no hardcoded default (P5 key-lifecycle hardening tracked separately).

Test plan

• Integration (real Postgres, IntegrationExternalFeedPasswordAtRest, 4): raw column carries SQUID_ENCRYPTED_V2: and not the cleartext secret; decrypt-on-read; read-both on a hand-inserted plaintext row; update re-encrypts; same-scope read+decrypt then unrelated SaveChanges keeps the column encrypted (the #437 flush-back regression, applied as a guard here).
• Regression: 411 feed-related unit + 9 integration tests green (no breakage to package fetch / registry auth / feed service).
• Crypto-envelope contract (round-trip / read-both / tamper) is unit-covered by the shared IVariableEncryptionService tests from #437; this persistence-layer change is correctly covered at the integration tier (Rule 9).
• CI: existing K8s Pipeline E2E (feed secrets) exercises feed consumption via the same decrypting provider seam.