feat(response-time-tracker): add safety and performance guards

[Yourbigmike]

close #648
Summary
Adds a validation/sanitisation guard layer and threat-model documentation to the V2 Response Time Tracker tool. All changes are isolated to tools/v2/team/response-time-tracker/.
Changes
guards/response-time-guards.mjs — 13 pure, synchronous guard functions:

• sanitizeText / sanitizeSubject — strip HTML tags, CR/LF/null, control characters (XSS & header injection prevention)
• validateEntryId / validateThreadId / validateTeamMemberId — allowlist pattern ^[a-zA-Z0-9_-]+$, length-capped at 64 (path traversal prevention)
• validateEmailField — rejects control characters, checks @ presence (header injection prevention)
• validateStatus — Set.has() allowlist for "met" | "missed" | "breached" (enum bypass prevention)
• validateDateString — rejects NaN dates (crash prevention)
• validateResponseTimeMs — enforces finite non-negative range [0, 7_776_000_000] (NaN/Infinity prevention)
• validateDateRange — span capped at 365 days, end ≥ start (unbounded query prevention)
• guardEntriesCount / guardMembersCount — reject arrays exceeding 10k entries / 500 members (DoS prevention)
• validateEntryInput — composes all field validators for a complete entry object
• validateServiceConfig — clamps delayMs to 10s max
  services/response-time-service.ts — Guards integrated at every entry point (getEntries, getMetrics, getTeamMembers, calculateMetrics, filterByDateRange, createResponseTimeService)
  docs/security-and-performance.md — Threat model documenting XSS, CRLF injection, ID traversal, NaN crashes, enum bypass, oversized collections, and unbounded date ranges. Performance notes for large entry histories, unoptimised array passes, and large team lists.
  tests/guards.test.mjs — 53 test cases covering every guard function including fixture validation.
  Documentation updated
• specs.md — added security constraints section with guard mapping
• docs/test-plan.md — added guard test walkthrough
• docs/review-notes.md — added guard layer to validated items
  Acceptance criteria
• Explicit handling for malformed or hostile input
• Avoids unnecessary work on large datasets (10k entry cap, 500 member cap, 365-day range cap)
• No existing security-sensitive app code modified
• All changes limited to tools/v2/team/response-time-tracker/
• 64/64 tests passing (53 guard + 11 service)