self-development: add stream-forwarding, trigger-filter, and handler-error conventions from recent reviews

[kelos-bot]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

Adds three evidence-backed agent conventions to the self-development AgentConfig
(AGENTS.md/CLAUDE.md, self-development/agentconfig.yaml, and
self-development/kelos-workers.yaml), each derived from a recent PR review.

1. Broaden the "vacuous substring assertions" rule to stream-forwarding tests

Motivated by PR #1189 (Stream agent output through kelos-capture):

• The Kelos Reviewer flagged (P3): "assertForwarded only checks substring presence; misses reordering/duplication" and recommended a byte-level comparison.
• cubic-dev-ai independently flagged the same line (P2, confidence 9): "Forwarding check too weak. Contains can miss dropped/reordered/duplicated lines. Compare normalized full output instead."
• The landed fix compares the forwarded stream byte-for-byte.

The existing convention was scoped narrowly to label: value printer/formatter
assertions; this extends it to writer/pipe forwarding tests.

2. Require author/subject filters on autonomous-run triggers

Motivated by PR #1241 (Add kanon-development TaskSpawners), whose new
event-driven triggers shipped without author scoping. The review flagged this
twice and both fixes were applied in that PR:

• P1 (confidence 9) on kanon-pr-responder.yaml: "Add an author filter to the pull_request_review trigger; without it, unapproved review comments can trigger autonomous task runs."
• P2 on kanon-reviewer.yaml: the issue_comment trigger was "not scoped to pull requests, so /kelos review on a regular issue can start the reviewer and make PR-only review commands fail."

Existing conventions only noted that issue_comment fires for both issues and
PRs; they did not state the baseline that every autonomous-run trigger must be
restricted to a trusted author allowlist and the intended subject
(commentOn: PullRequest for PR-only commands). This adds that rule so future
spawners ship the filters up front instead of being corrected in review.

3. Distinguish "not found" from "lookup failed" in request handlers

Motivated by PR #1238 (Add WebhookGateway CRD), whose request handlers
conflated API lookup errors with empty results. The review flagged this
repeatedly and the maintainer fixed every instance (see his summary on the PR):

• P1 (confidence 9): "TaskSpawner list errors are treated as an empty match set, so transient API failures can silently drop webhooks with a 200 response." Fix: "listGatewayScopedSpawners now returns the error; the handler responds 5xx so a transient API failure is retried instead of being swallowed as a 200."
• Fix: "gateway Get now returns 404 only on IsNotFound; other errors (RBAC/transient) return 500."

The existing "fail fast on invalid configuration" rule covers startup
config/secrets, not request-time API reads. This adds a distinct convention so
handlers and reconcilers propagate List/Get errors as 5xx (the sender
redelivers) instead of answering 200 with an empty result that silently
drops the event.

Files updated (the canonical agent-rule locations; CLAUDE.md is a symlink to AGENTS.md):

• AGENTS.md / CLAUDE.md (substring rule + handler-error rule)
• self-development/agentconfig.yaml
• self-development/kelos-workers.yaml

Which issue(s) this PR is related to:

N/A

Special notes for your reviewer:

Convention-only change; no code or behavior is affected. Several earlier
kelos-config-update-* PRs are still open (#1219, #1214, #1162, …); these are
distinct, focused changes and do not overlap with them.

Does this PR introduce a user-facing change?

NONE