Backlog Pattern Proposals Triage and Generation

### Context
The patterns repository has a significant number of open issues where community members have proposed new patterns that were never progressed. These proposals were submitted under the old contribution model, which required contributors to write fully-formed patterns themselves — a high bar that meant most submissions stalled in triage.

With the new AI-assisted contribution workflow now validated (Notion form → skill-generated draft → review), we have the means to revisit these proposals efficiently. The submitted issues already contain the raw material the skill needs: a pattern description, SCI impact reasoning, and supporting references. The bottleneck is no longer drafting — it's deciding which proposals are worth generating.

This issue tracks a structured triage sprint to work through the open proposal backlog, make an accept/defer/close decision on each, and use the skill to generate patterns for those we accept.

### What needs to happen
- [ ] Compile a list of all open pattern proposal issues (label: `proposed-pattern` or equivalent)
- [ ] For each proposal, make one of three triage decisions:
- **Generate** — the proposal has sufficient substance; use the green software pattern skill to produce a draft
- **Defer** — the concept is valid but the proposal lacks enough detail; comment on the issue requesting more information from the submitter
- **Close** — the proposal is out of scope, superseded by an existing pattern, or no longer relevant; close with a brief explanation
- [ ] For each accepted proposal, run it through the pattern skill and raise a PR in the standard way
- [ ] Notify original submitters of the outcome on their issue

### Acceptance criteria
- Every open pattern proposal issue has been triaged with a documented decision
- All accepted proposals have a corresponding generated pattern PR raised
- Original submitters have been acknowledged — especially those whose proposals are being picked up
- No proposal is left in limbo with no response

### Dependencies
- Green software pattern skill (validated and live)
- Reviewer capacity: generated patterns will need the standard submitter-approve → team-review sign-off before merging
- Pattern catalogue harmonisation (#) — triage decisions should be informed by what already exists in the catalogue to avoid generating duplicates

### Notes
When triaging, watch for:
- **Commercial disclosure** — some proposals (e.g. #226) are submitted by vendors with a product interest. The pattern itself may still be valid, but the generated version should be vendor-neutral
- **SCI impact accuracy** — proposals vary in the quality of their SCI reasoning; the skill will surface issues but the reviewer should check E vs I attribution carefully
- **Scope creep** — proposals that try to cover too much ground should be scoped down to a focused, architectural pattern before generation