feat: add [TRIAGE_UPDATE] marker extraction and auto-PATCH (Phase 2)

- Add _parse_triage_update_marker() parser following existing marker pattern
- Add [TRIAGE_UPDATE] instructions to system prompt with grounding rules
- Add QuestionItem.options support in question parser
- Wire triage extraction into both main and branch-aware chat paths
- Auto-PATCH session: AI only fills null fields (manual edits win)
- Evidence items: AI appends only, never modifies existing
- Return triage_update in ChatMessageResponse for frontend header sync

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

backend/app/services/assistant_chat_service.py

@@ -84,9 +84,38 @@ scope narrows it to this endpoint.
 - Commands should be PowerShell unless context indicates Linux/Mac
 - For GUI-only steps, omit `command`
 
+**[QUESTIONS] `options` field:**
+When a question has a small, constrained set of answers (yes/no, 2-4 choices), include \
+an `options` array with the answer labels. The engineer will see these as quick-reply buttons. \
+Example: `{"text": "Did nslookup time out or return a wrong IP?", "options": ["Timed out", "Wrong IP", "Both"]}`
+Omit `options` when the answer is open-ended.
+
 **Both markers are stripped from display** — the engineer sees them as interactive UI cards, \
 not raw JSON. Put analysis BEFORE markers. Markers go at the END of your response.
 
+## Triage Context Extraction
+
+When you learn NEW facts about the case from the engineer's messages, emit a \
+[TRIAGE_UPDATE] marker with a JSON object containing ONLY the fields that changed. \
+Do NOT repeat unchanged fields. Only emit this marker when you have grounded evidence — \
+never guess or fabricate. If you are not confident, do not emit the marker.
+
+Fields:
+- `client_name` — the MSP client/company being helped (only from explicit mention or ticket data)
+- `asset_name` — the device, user, or asset being troubleshot
+- `issue_category` — human-readable category like "DNS / Networking", "Microsoft 365", "Active Directory"
+- `triage_hypothesis` — your current working hypothesis about the root cause (update as evidence changes)
+- `evidence_items` — NEW evidence to append: `[{"text": "description", "status": "confirmed|ruled_out|pending"}]`
+
+Example (only include fields that have new information):
+
+[TRIAGE_UPDATE]
+{"issue_category": "DNS / Networking", "triage_hypothesis": "Corrupted DNS cache on NIC", "evidence_items": [{"text": "Gateway 192.168.1.1 reachable", "status": "confirmed"}, {"text": "DNS 1.1.1.1 timeout", "status": "ruled_out"}]}
+[/TRIAGE_UPDATE]
+
+Place [TRIAGE_UPDATE] AFTER [QUESTIONS]/[ACTIONS] markers, before [FORK] if present. \
+This marker is optional — only emit it when you learn something new.
+
 ## Using the Team's Flow Library
 Your team has built troubleshooting flows in ResolutionFlow. When relevant flows \
 appear in the context below, reference them by name so the engineer can launch them \