actor filter: only the literal `*[bot]` is a wildcard — other patterns silently degrade to exact match

### Summary

`exclude_comments_by_actor` / `include_comments_by_actor` document wildcard support, but only the **exact literal** `*[bot]` is a wildcard. Every other wildcard-looking value silently degrades to an exact-match on a login that will never exist — so the field looks like it is filtering and filters nothing.

### Where

`src/github/utils/actor-filter.ts` (read at `5ef2e550a465a721f4f45e4a7d3c340c873e1dcc`, v1.0.190):

```ts
export function actorMatchesPattern(actor: string, pattern: string): boolean {
// Exact match
if (actor === pattern) return true;

// Wildcard bot pattern: "*[bot]" matches any username ending with [bot]
if (pattern === "*[bot]" && actor.endsWith("[bot]")) return true;

// No match
return false;
}
```

### Why it is easy to get wrong

`action.yml` describes both inputs as "**Supports wildcards**: `'*[bot]'` matches all bots, `'dependabot[bot]'` matches specific bot." Read naturally, that says the field supports *wildcards* and gives one example. In practice `*` is not a metacharacter anywhere — it is part of one hardcoded string comparison.

Values that a maintainer would reasonably expect to work, and what actually happens:

| value | expected | actual |
|---|---|---|
| `*[bot]` | all bots | ✅ all bots |
| `*bot*` | anything containing "bot" | ❌ matches only a user literally named `*bot*` |
| `dep*` | prefix match | ❌ matches only a user literally named `dep*` |
| `*[BOT]` | all bots | ❌ never matches (case-sensitive, and `!== "*[bot]"`) |
| `*` | everyone | ❌ matches only a user literally named `*` |

**The failure is silent and asymmetric.** On `exclude_comments_by_actor` a non-matching pattern means the actor is **not excluded** — the field reads as a filter that is on, while the comments it was meant to drop still reach the prompt. There is no warning in the log and no way to tell "filtered nothing" from "nothing to filter".

Related: matching is case-sensitive (`actor === pattern`), so a login whose canonical case differs from the configured string never matches. On `include_comments_by_actor` that drops *every* comment.

### Suggestions (any one would remove the trap)

1. **Warn on unmatched-looking patterns**: if a pattern contains `*` and is not exactly `*[bot]`, log a warning that it will be treated as a literal login.
2. **Document the exact limitation** in `action.yml` — replace "Supports wildcards" with "the single supported wildcard is the literal `*[bot]`; all other values are exact, case-sensitive login matches".
3. Optionally support real glob semantics, in which case please note the behaviour change for anyone currently relying on exact matching of a login that contains `*`.

Option 2 alone would be enough for us — the problem is that the current wording invites patterns the code cannot honour.

### How we hit it

We were writing a shared `claude.yml` for 21 private repos and reviewing every input against its consuming code before rolling it out. The value we had chosen (`*[bot]`) happens to be the one that works; the review is what showed us that a neighbouring value would not, and would not say so.