Container mounts the operator's ~/.config/gh; agent acts as that human on GitHub #157

Follow-up to #100, which removed the ~/.claude bind-mount. The GitHub credential has the same shape and is still mounted.

README.md and the container docs run the agent with -v ~/.config/gh:/home/claudetm/.config/gh, handing it the operator's gh OAuth token. Every push, PR, comment and merge the agent makes is then attributed to that person, with their full scope — including repos the agent has no business touching. It is the same class of problem as #100 (a human's personal credential standing in for the agent's), just for a different provider.

Not fixed in #156 deliberately: that PR only moved the container-side path from /root to /home/claudetm, so it neither introduced nor widened the exposure, and a real fix is a redesign — GH_TOKEN/GITHUB_TOKEN from a scoped, rotatable credential (a fine-grained PAT or a GitHub App installation token), applied consistently across ~8 files. Bundling that into an 81-file PR would have buried it.

Acceptance

• No container mounts or reads a human's ~/.config/gh.
• The agent authenticates to GitHub with a scoped, rotatable credential, revocable without touching anyone's personal gh login.
• Least privilege: only the repos the agent is meant to work on.
• Verified that gh inside the container picks up the token — gh honours GH_TOKEN, so this is likely env-only, but confirm against the code paths that shell out to gh before documenting it.

Found by CodeRabbit while reviewing #156.