CodeLens scans `.env` files despite paste interception being intentionally disabled there

[NK2552003]

The README correctly states that .env and .env.local files are excluded from paste interception because secrets are intentional there. However, CodeLens scanning is still active on those files, producing warnings on content the user deliberately placed there.

Problem

A developer opens their .env file and sees CodeLens warnings above DATABASE_URL, STRIPE_SECRET_KEY, and every other intentional secret. The natural response is: "PasteShield is warning me about my .env file — this tool is too noisy." This erodes trust in PasteShield's signal quality across the board, including the legitimate detections it surfaces elsewhere.

The inconsistency is explicit in the README:

.env and .env.local files are always excluded from paste interception

...but the same exclusion does not apply to CodeLens. This is a UX contradiction that needs to be resolved.

Proposed solution

Scope:

• Extend the .env exclusion to CodeLens scanning by default
• Add an opt-in setting for users who explicitly want CodeLens on .env files:

  // Default false — .env files are excluded from CodeLens scanning
  "pasteShield.codeLensScanEnvFiles": false

• Extend the exclusion to common env file variants: .env, .env.local, .env.development, .env.production, .env.test, .env.*.local
• Update the README to clearly document the distinction between paste interception exclusions and CodeLens exclusions

Acceptance criteria

• CodeLens does not activate on .env* files by default
• pasteShield.codeLensScanEnvFiles: true re-enables CodeLens on env files for opt-in users
• All common .env variants are covered by the exclusion
• README updated to document the exclusion behaviour accurately