fix: refuse create_filter actions that apply TRASH or SPAM

[Kaliratech]

Fixes #23.

The problem

create_filter passed add_label into addLabelIds with no validation of the value:

if (args.add_label) {
  action.addLabelIds = await (provider as GmailProvider).resolveLabelIds(
    [args.add_label as string], { create: args.create_label as boolean | undefined }
  );
}

Gmail's system label IDs are literally TRASH and SPAM, so a single call could install a filter that silently destroys or junks every future matching message.

A filter is not a one-off action, it is persistent server-side state. It keeps applying to mail that arrives long after the call that created it, and nothing in the client transcript shows it working. Combined with #22, where attacker-controlled email text reached the model outside the fences, an injected instruction had a durable and invisible payload available to it.

For anyone comparing against older versions: 0.2.0 had an allowlist here, but it validated which action keys could appear (addLabelIds, removeLabelIds), not which label values were acceptable, so TRASH passed through there too. This is a longstanding gap rather than a regression.

The fix

Resolve first, then refuse if the resolved IDs include a destructive system label. Checking after resolution is deliberate: resolveLabelIds maps the name "Trash" to the ID TRASH through its byName lookup, so a check on the raw argument would be bypassable by passing the name instead of the ID.

archive and mark_read are untouched, since they only ever remove INBOX and UNREAD.

If you would rather keep the capability reachable, an explicit opt-in argument or an env gate would also close the injected-call path. The goal is only that a model reading untrusted mail cannot arrive here by accident.

Tests

Two added to tests/tools/gmail-only.test.ts.

The load-bearing assertion is expect(filters.create).not.toHaveBeenCalled(), not merely that an error came back: the point is that no filter reaches Gmail on the refusal path. Both fail without the guard:

⎯⎯⎯ Failed Tests 2 ⎯⎯⎯
Tests  2 failed | 19 passed (21)

The SPAM test passes the ID form rather than a lowercase name, with a comment explaining why: the test mock passes unknown labels through untouched, so "spam" would never become "SPAM" in the test and the assertion would have exercised the mock instead of the guard.

Suite

256 passed across 22 files, excluding tests/signal-resilience.test.ts. That file passes 4/4 on its own but is timing-sensitive under parallel load; it failed the same way on unmodified main on this machine before any of my changes, so it is unrelated.

Also verified against a real Gmail account: a create_filter call with add_label: "TRASH" is refused, and list_filters output on the target account is identical before and after, so nothing is created on the refusal path.