docs: document project configuration trust model for PR workflows

[juniperbevensee]

Summary

• Documents that claude-code-action restores project-level configuration (.claude/, .mcp.json, etc.) from the PR base branch before Claude runs, and what that protects against
• Adds guidance for users of claude-code-base-action or direct claude -p invocations who need to handle project configuration themselves when processing PR code
• Extends the existing pull_request_target section with a complementary section covering hooks and project config more broadly

Context

The action already implements restoreConfigFromBase() in src/github/operations/restore-config.ts, which replaces PR-controlled configuration paths with base-branch versions. The source comments describe the threat model clearly, but this behavior isn't covered in the user-facing security docs. Users of claude-code-base-action or raw claude -p have no equivalent guidance.

This addition makes the existing protection visible and gives actionable patterns for workflows that don't use the full action.

Changes

One new section in docs/security.md ("Project-Level Configuration in PR Workflows") with three subsections:

1. What project-level config is and why it matters in PR workflows
2. How claude-code-action handles it (base-branch restoration, .claude-pr/ preservation)
3. Options for claude-code-base-action / claude -p users (base-only checkout, manual restoration, or switching to the full action)

[juniperbevensee]

Major company fixing this: alibaba/TorchEasyRec#515

[caioribeiroclw-pixel]

This is a useful security-doc addition. One small thing I would consider adding: make the restoration step produce an explicit review/audit artifact, not just perform the replacement silently.

For PR workflows the most useful artifact would be tiny, for example:

• project config paths restored from base (.claude/, .mcp.json, CLAUDE.md, etc.)
• PR-authored config paths quarantined into .claude-pr/
• any config path missing on base and therefore removed
• whether hooks/MCP definitions came from base or PR
• the base ref / head sha used for the decision

That gives reviewers and follow-up workflows something deterministic to inspect without executing PR-controlled config. It also helps users of claude-code-base-action or direct claude -p copy the trust model safely: “restore trusted config” plus “prove what was restored/quarantined.”

I would especially call this out near the .claude-pr/ paragraph, because otherwise a workflow can be secure but opaque: Claude can inspect PR-authored config, but humans/CI may not have a clear receipt of which config was trusted versus only reviewed.