Elon gate blocks pull requests to repositories the user does not control #264

What: The project-direction Elon gate blocks gh pr create for an upstream contribution unless its public body carries an Elon record.
Why: The gate checks every gh pr create / gh api .../pulls by body content and has no notion of the target repository's owner, so third-party upstream PRs need the private workflow's record in their public text.
So what: The owner decides whether PRs and Issues in repositories the user does not control are exempt (or keep the record elsewhere, such as the linked task record); a worker then changes the gate.

Observed

lukemaj/chiaki-web#6 needs one upstream PR to chiaki-ng/chiaki-ng from the fork lukemaj/chiaki-ng. The owner's brief asks for an English, factual upstream PR with no AI-agent boilerplate beyond what the upstream guide requires. bin/project-direction (elon_gate, ELON_FIELDS, API_CREATE) blocks that PR without the four fields. The gate has no repository exemption (checked in 17.4.6 source).

Decision needed

• Exempt create commands whose target repository (-R/--repo, or the API path) is outside the user's accounts and organizations, with the Elon record kept in the owning task record instead; or
• Keep the gate universal (upstream PRs carry the record).

Acceptance criteria

• The gate behaves as decided for upstream targets, with a test for both an owned and a third-party repository.

Non-goals

• Changing the record requirement for owned repositories.

Elon record

• Requirements and who asked: owner brief on lukemaj/chiaki-web#6 (minimal upstream PR, no agent boilerplate) versus the core rule that every Issue and PR carries the record.
• Deleted: circumventing the gate (for example, opening the PR another way or editing the body afterwards).
• Bottleneck: owner decision on scope of the rule.
• Checked myself: read elon_gate and the create-command matching in bin/project-direction (17.4.6); a reviewer on lukemaj/chiaki-web#8 reached the same conclusion from the gate's tests.