human gate writes a dotted context key (human.gate.text) that #82 now refuses as a tool_env name — provide a POSIX-identifier alias engine-side

Consequence of the owner ruling implemented in #82 (non-POSIX-identifier `tool_env` names are refused at lint and preflight): consumers cannot rename `human.gate.text` because the engine produces it — `modules/loop-pipeline/.../handlers/human.py` writes the gate's captured text under that dotted key. resolver-dot-graph's rename PR (microsoft/amplifier-resolver-dot-graph#148) renamed every repo-owned key but had to leave this one, flagged.

Ask: the human-gate handler also exposes the captured text under a POSIX-identifier key (e.g. `human_gate_text`) — additive, so existing readers of the dotted key keep working — and the docs/EXTENSIONS entry for the human gate names the identifier form as the one to use in `tool_env`. Hermetic test: a graph with `tool_env="human_gate_text"` round-trips the gate's value to the command; the dotted form is still refused by lint with a message pointing at the alias. Ledger touch if a row covers the human gate. No sanitization, no dual emission — one canonical identifier the engine writes.

Start in modules/loop-pipeline/.../handlers/human.py, then read the docs/EXTENSIONS entry for the human gate and the lint/preflight behavior from #82. Add the requested POSIX-identifier alias while retaining compatibility with the dotted key, and add the hermetic graph test where tool_env="human_gate_text" reaches the command. Confirm the dotted form remains refused with a message pointing to the alias.

Written by the indexing model from the issue text.