Fix mismatched request_id in ITSM scenario 33

[fanny-riols]

Summary

In the ITSM dataset (data/itsm_dataset.json), scenario id: "33" had a mismatched request_id:

• user_goal.information_required.request_id and seed_data.request_id were set to REQ-SW-066666
• The scenario's own ground_truth.expected_scenario_db.requests only contains a record keyed REQ-SW-659dac3f4833 — same employee, same Salesforce request, different ID string.

Fix

Updated scenario 33 so the request_id is consistent everywhere: seed_data, information_required, negotiation_behavior, resolution_condition, the get_request_status tool call/response and its message in expected_trace, and the two spoken-utterance digit spellouts (now spelling out six five nine d a c three f four eight three three). EMP066666 references were left untouched since that ID is correct and already matches the DB.

Investigation scope

I checked whether this was an isolated authoring mistake or a systemic dataset bug:

• Scanned all information_required ID-like fields (*_id, *_code) against ground_truth.expected_scenario_db across all three datasets:
  • ITSM (80 scenarios): only scenario 33 had a genuine mismatch.
  • HR (83 scenarios): 34 fields flagged, but all verified false positives — either deliberately wrong/outdated values the scenario is designed to test (e.g. scenario 8.2's outdated clearance_code, where the goal is for the agent to reject it), or destination values for a transfer that legitimately don't exist yet (new_facility_code, new_state_code).
  • Airline (50 scenarios): no matching ID fields at all — no mismatches.
• Conclusion: this is an isolated authoring bug specific to scenario 33's request_id. No other scenario in ITSM, HR, or Airline has this issue.

Also, on all our past runs, the get_request_status call never once succeeded for that scenario because it always used an id that wasn't present in the DB.