Add co-activation quality testing for way matching

[aaronsb]

Context

The way matching system uses additive triggering — multiple ways can fire on a single prompt when they share relevant vocabulary. This is by design: a prompt like "migrate the database schema" legitimately needs guidance from both delivery/migrations (schema change mechanics) and architecture/design (target architecture).

Currently the test framework (fixture + integration) measures single-expected-way accuracy. It validates that the right way fires, but doesn't measure whether the set of co-activated ways is appropriate.

What's needed

A test layer that validates co-activation quality:

• Prompts designed to trigger 2+ related ways, with expected sets
• Measurement of whether co-activated ways provide complementary (not redundant) context
• Detection of unwanted co-activation (unrelated ways bleeding in)

The activation test (step 5) now tests co-activation live, but the automated harness doesn't yet support multi-expected-way fixtures.

Suggested approach

Extend test-fixtures.jsonl format to support "expected": ["way-a", "way-b"] arrays alongside the existing single-string format. Add co-activation test cases for known overlap areas: schema/design, error/debugging, security/deps.

[aaronsb]

Activation test findings (PR #30)

The activation test (8/8 PASS) revealed concrete co-activation patterns worth capturing as test cases:

Step 5 — Parent agent co-activation

Prompt: create a migration to alter the users table and add an index on the email column

• delivery/migrations fired (expected — migration, alter, table, column, index)
• delivery/patches co-fired (vocabulary overlap in delivery domain)
• architecture/design did NOT fire (contrary to initial expectations)

Patches co-activating alongside migrations is reasonable — both are delivery-domain ways providing complementary guidance (schema safety vs diff generation).

Step 7 — Subagent injection co-activation

Prompt (Task tool): write unit tests for a utility module with jest

• code/testing injected (expected — unit tests, jest)
• architecture/design, code/performance, delivery/patches also co-activated via injection pipeline

The subagent injection pipeline appears more generous than the parent prompt pipeline — 4 ways fired for a narrowly-scoped prompt. This suggests the check-task-pre.sh scoring may have lower effective discrimination than check-prompt.sh, or the prompt preamble ("DIAGNOSTIC: List every system-reminder block...") contributed additional vocabulary matches.

Implications for test harness

1. Co-activation fixtures should cover both parent (check-prompt) and subagent (check-task-pre) paths
2. The subagent pipeline's broader activation warrants its own test cases — different code path, potentially different thresholds
3. delivery/patches co-activating with delivery/migrations is a good candidate for the first multi-expected fixture