Merge canary into main: path security, Zod validation, AI enhancements, infra updates

[Copilot]

• Fix Issue 1: Polynomial ReDoS in _to_seconds regex — bound quantifiers ({1,15}, {1,10}), replace \s* with [ ]?, order units longest-first
• Fix Issue 2: Polynomial ReDoS in from...to regex — replace [^\s]+(?:\s*[a-z]+)? with [0-9][0-9.]*[a-z]*(?:[ ][a-z]{1,12})?
• Fix Issue 3: Polynomial ReDoS in long duration regex — same fix as Issues 2/4
• Fix Issue 4: Polynomial ReDoS in set to / make it regex — same fix
• Also fixed identical vulnerability in m2 and m3 patterns (at/from and for/span patterns)
• Validated all fixes with functional and adversarial smoke tests (5000-char inputs complete in <0.2ms)
• Code review passed — no comments

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[sr2echa]

@copilot Fix these issues:

Please resolve the following Polynomial ReDoS vulnerabilities identified by CodeQL in backend/main.py. For each issue, rewrite the regex to be "linear" or "possessive" to prevent catastrophic backtracking.

Issue 1: Duration Unit Parsing
File: backend/main.py

Location: Inside the _to_seconds function (the re.finditer call).

Problem: The group (?P\d+(?:.\d+)?)\s* combined with the long list of optional units can be exploited if a user provides a very long string of numbers and spaces without a valid unit terminator.

Fix Required: Simplify the numeric matching and ensure the unit boundaries are strict.

Issue 2: "From...To..." Extraction
File: backend/main.py

Location: m = re.search(r"from\s+([^\s]+(?:\s*[a-z]+)?)\s+to\s+([^\s]+(?:\s*[a-z]+)?)", text)

Problem: The nested optional groups ([^\s]+(?:\s*[a-z]+)?) are the culprit. When the engine fails to find a match, it tries every possible permutation of spaces and letters, leading to exponential complexity (specifically triggered by strings like "from !" followed by many "aa").

Fix Required: Refactor to avoid nested quantifiers. Use a simpler non-whitespace match or a non-backtracking approach.

Issue 3: "Long" Duration Parsing
File: backend/main.py

Location: m4 = re.search(r"(?:to\s+)?([^\s]+(?:\s*[a-z]+)?)\s+long", text)

Problem: Similar to Issue 2, the ([^\s]+(?:\s*[a-z]+)?) pattern is unstable. CodeQL notes it fails on strings with many repetitions of !.

Fix Required: Replace the capture group with a more restrictive pattern that doesn't "loop inside a loop."

Issue 4: "Set to/Make it" Parsing
File: backend/main.py

Location: m5 = re.search(r"(?:set\s+(?:it\s+)?to|make\s+(?:it\s+)?)\s+([^\s]+(?:\s*[a-z]+)?)", text)

Problem: The combination of multiple optional words (it, to) followed by the same problematic ([^\s]+(?:\s*[a-z]+)?) group. This is vulnerable to "ambiguous matching" where the engine gets lost in the spaces.

Fix Required: Flatten the regex and use atomic grouping or simpler delimiters.

[Copilot]

@copilot Fix these issues:

Please resolve the following Polynomial ReDoS vulnerabilities identified by CodeQL in backend/main.py. For each issue, rewrite the regex to be "linear" ...

Fixed in 6dcd2f2. Summary of each change:

Issue 1 (_to_seconds regex): Replaced unbounded \d+(?:\.\d+)?\s* with [0-9]{1,15}(?:\.[0-9]{1,10})?[ ]? — bounded quantifiers cap backtracking depth, \s* → [ ]? removes space-based amplification. Units reordered longest-first to reduce alternation backtracking.

Issues 2–4 (and also m2/m3 which had the same pattern): Replaced [^\s]+(?:\s*[a-z]+)? with [0-9][0-9.]*[a-z]*(?:[ ][a-z]{1,12})?. The key property: [0-9.], [a-z], and [ ] are fully disjoint character classes, so there is no position where the regex engine can "trade" characters between groups — eliminating the exponential ambiguity. \s* (zero-or-more spaces, which overlapped with the preceding non-space group) was replaced with [ ] (exactly one literal space).

Adversarial inputs of 5,000 characters now complete in <0.2 ms. CodeQL reports 0 alerts.