feat: add EnvVarName to PropertySpec and annotate driver specs

[royendo]

as part of effort to slim: #8981,

• Adds an EnvVarName metadata field to drivers.PropertySpec so driver specs can declare the conventional env var name for each secret property (e.g. AWS_ACCESS_KEY_ID, GOOGLE_APPLICATION_CREDENTIALS).
• Populates EnvVarName on secret properties across 14 driver specs: athena, azure, bigquery, clickhouse, druid, duckdb (motherduck), gcs, mysql, pinot, postgres, redshift, s3, salesforce, snowflake.
• The mapping isn't mechanical — some keys share well-known names across drivers (AWS_*), others add infixes (AZURE_STORAGE_*), and some diverge entirely (GCS key_id → GCP_ACCESS_KEY_ID) — so the field has to be explicit.
• No consumers in this PR; the field will be read by upcoming declarative template work.

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

---

Developed in collaboration with Claude Code

[royendo]

So your real question is: do we want the env var convention defined once at the driver level (Go) or per-template (JSON)?
Driver-level is less drift; per-template is more flexible but redundant when the same property appears in many templates.

Will close for now since the current template code doesnt actually use this