fix: Include verification rules in affectedRequestIds to prevent silent check loss on redirect chain merge

[cursor]

Description

Bug: Verification rules were excluded from the affectedRequestIds set built in applyRules(). This set controls whether redirect chains are merged or split in processRedirectChains(). When a chain is merged, only the last hop's checks survive (checks: last.checks), silently dropping any verification checks applied to non-final hops.

Concrete trigger: A user adds a verification rule (e.g., assert status equals 302) that matches a request in a redirect chain (e.g., POST /login → 302 → GET /dashboard). The verification rule correctly adds a check to the first hop's snippet, but since verification is not in affectedRequestIds, the chain merges and the check is silently removed from the generated k6 script. The user sees no error — the check simply does not appear in the output.

Root cause: In src/rules/rules.ts, the affectedRequestIds collection handled parameterization, customCode, and correlation rule types, but returned [] for verification, even though verification rules add checks to request snippets via matchedRequestIds.

Fix: Added 'verification' to the condition that collects matchedRequestIds into affectedRequestIds, ensuring redirect chains containing verification-matched requests are split rather than merged.

How to Test

1. All existing tests pass (281/281), typecheck passes, lint passes.
2. New test case added: does not drop checks from non-final hops when they are in affectedRequestIds — verifies that a 3-hop redirect chain with checks on non-final hops preserves all checks when the chain is affected.
3. Manual scenario: Create a recording with a redirect chain (e.g., login flow), add a verification rule on the first request, generate a script, and confirm the check appears in the output.

Checklist

• I have performed a self-review of my code.
• I have added tests for my changes.
• I have commented on my code, particularly in hard-to-understand areas.