fix(ci): let AI code review run on external contributor PRs

[jam-jee]

Issue

The AI code review workflow fails on every pull request from a fork, before any
review happens:

Checking permissions for actor: <author>
Permission level retrieved: read
[warning] Actor has insufficient permissions: read
[error] Action failed with error: Actor does not have write permissions to the repository

Example: run 31217496013 on #6166.

The collaborator gate, checkout, diff fetch and credential steps all succeed —
claude-code-action then runs its own actor permission check and exits. The net
effect is that the reviewer only ever ran for collaborators, and was a silent
no-op on external contributions.

Cause

claude-code-action requires the PR author to have write access. The check is
gated on the event being an "entity" context, which pull_request_target
satisfies, so it applies regardless of the action's mode. allowed_non_write_users
(which requires the github_token input this workflow already passes) is the
only supported way to run the action for read-access authors.

Change

Set allowed_non_write_users: "*", plus compensating controls.

That default exists to protect the action's normal @claude usage, where a
read-only user's comment becomes the prompt. It does not apply here:
pull_request_target always runs the base-branch copy of this workflow, so the
review prompt is fixed by maintainers and cannot be supplied by a fork.

What contributors can influence is the content the model reads — the diff, code
comments, commit messages, and the PR title/body/comments. That is a
prompt-injection surface, so this PR also narrows the blast radius:

• Deny reads on sensitive paths — /proc, /sys, ~/.aws, the Actions
  _temp directory, and .git/config. The inline-comment tool is an output
  channel, so this closes the inject-then-exfiltrate-via-comment path. Verified:
  a /proc/self/environ read is blocked while ordinary file reads still work.
• Prompt hardening — the model is told to treat all contributor-authored
  content strictly as data, never as instructions, and to report any attempted
  injection in its review summary.

Unchanged existing protections:

• Fork PRs still require maintainer approval via the manual-approval
  environment.
• No Bash, Write or Edit — the model cannot execute anything.
• Checkout remains the trusted base repo; fork code is never executed.
• The assumed role remains least-privilege: bedrock:InvokeModel on a single
  inference profile, 1 hour max session.

Residual risk

Worst case under a successful injection is disclosure of a short-lived session
token whose only permission is invoking one Bedrock model — i.e. token spend, not
data or infrastructure access.

Testing

• Workflow YAML parses; new inputs resolve as expected.
• --disallowedTools rule syntax validated against Claude Code: no
  unrecognized-rule warnings, /proc/self/environ denied, normal reads allowed.
• As always with pull_request_target, the change only takes effect once merged
  to master, since the base-branch copy of the workflow is what runs.