docs(config): 补 .env.example 并修正 .gitignore 误伤模板

.gitignore 的 `.env.*` 会把 `.env.example` 一起排除，等于把变量清单挡在仓库外，
接手的人只能翻 application.yml 逐个猜要配什么。加 `!.env.example`（含
`.sample`、`.template`）例外，规则顺序放在忽略之后。

同时补 .env.example：从 application.yml 与代码里实际提取 20 个变量，分组注明
默认值与是否必须替换。三个必改项（DB_PASS 无默认、GATEWAY_TOKEN 占位、
BIZ_TOKEN_SECRET 与 BIZ_PII_KEY 为 dev-only）单独标出。

本文件只放占位值；真实的 .env 仍不入库。另注明工程不自动读 .env
（未引入 dotenv），必须由启动脚本加载或 docker compose --env-file 注入——
这一条不说清，会有人建了 .env 直接启动然后发现 DB_PASS 还是缺。

CONTRIBUTING.md

@@ -59,6 +59,8 @@ rawRef 指向不存在的行时，原先抛 NPE 被全局兜底成 500，
 | 运行产物 | 日志、`*.jsonl`、证据 `raw/`、截图 |
 | 公司无关资料 | 员工绩效、客户名单、采购函、其他项目报价 |
 
+**唯一例外是 `.env.example`。** 它是变量清单模板，必须入库——不入库接手的人就不知道要配哪些变量，只能去翻 `application.yml` 逐个猜。模板里只放占位值，真实值填在本地 `.env` 里。新增环境变量时同步更新它，否则清单很快就不准了。
+
 `.gitignore` 已经覆盖上述路径，但**它只挡新增，不挡已提交**。加文件前先 `git status` 看一眼。
 
 判断标准很简单：**这个文件一旦公开，会不会造成损失？** 会，就不要放进来。Git 的历史是追加式的，删除只影响最新版本，历史里那份永远在。