Make COMMENT_AUTHOR_ASSOCIATION allowlist configurable per repo

[kamilio]

Problem

The github-issue-opened automation (and likely the others in github-workflows) hardcodes the allowed COMMENT_AUTHOR_ASSOCIATION values to OWNER, MEMBER, COLLABORATOR. Issues opened by users with association CONTRIBUTOR are rejected by the guard:

Automation "github-issue-opened" does not allow COMMENT_AUTHOR_ASSOCIATION "CONTRIBUTOR". Allowed values: OWNER, MEMBER, COLLABORATOR.

Example run: https://github.com/poe-platform/creator_docs/actions/runs/24894253350/job/72894574724#step:7:11

Functionally the workflow behaves correctly — the guard step has continue-on-error: true, so the overall guard job still succeeds and the run job is skipped. But:

1. Step 7 shows as a red ✗ in the UI, which looks like a broken CI.
2. There's no way to let a CONTRIBUTOR trigger the automation on a repo where that's the desired policy, short of bumping their repo permission to collaborator.

What's missing

Neither of the layers a consumer repo owns exposes this:

• .poe-code/github-workflows/variables.yaml only holds prompt variables (response_style, pull_request_guidelines, …). No authorization knobs.
• The reusable workflow poe-platform/poe-code/.github/workflows/gh-github-issue-opened.yml@main doesn't accept an ALLOWED_ASSOCIATIONS input.
• The consumer workflow (.github/workflows/poe-code-github-issue-opened.yml) just forwards inputs to the reusable workflow.

The allowlist lives inside the poe-code github-workflows require-user-allow <name> CLI command.

Suggested fix

Make the allowlist configurable per automation. A couple of options:

1. Variables file: add an allowed_associations key to .poe-code/github-workflows/variables.yaml (per-automation or global), and have require-user-allow read it.
2. Workflow input: add an optional ALLOWED_ASSOCIATIONS input to the reusable workflows so the consumer workflow can pass OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR (or similar).

Option 1 is nicer for consumer ergonomics (no regenerate of the installed workflow); option 2 is simpler and keeps config in one file.

Either way the default should stay the current strict set; this is purely about letting a repo opt in.

Also worth considering

Right now the guard failure shows as a red ✗ on a passing job. Would be nice if require-user-allow exited 0 with a neutral "skip" signal (and the guard step just emitted should_run=false directly) so the UI doesn't look broken when the automation is correctly declining to run.

[kamilio]

Fixed in c2fcf6c..7de1866 on main; stable release to poe-code@latest will roll out from the main-branch workflow.