BUG: Appointment follow-up – time choice not recognised

Repro from live test:

1) Outbound EOT 12-month message sent via /api/lia/outbound for:
   - customer_id = 44f01301-7a59-4e34-b0a8-d0d89e061aab
   - campaign = TEST_12_PCP
   - stage = 12

2) Customer reply on WhatsApp:
   "Hi can I pop in on Saturday ?"
   → LIA responds correctly with an appointment-style reply offering time options (e.g. two slots).

3) Customer then replies:
   "How about 11:00am ?"

ACTUAL:
LIA sends another generic EOT/engagement intro:
   "Great to hear from you, LiaTest. You're in a strong position at the moment – your Audi's value is good and you've got unclaimed loyalty savings reserved as an existing Audi customer..."
i.e. the engine behaves like a fresh conversation instead of confirming the time.

EXPECTED:
Given:
- appointment_status is already "INVITED" for this conversation
- stage = "12"
- recent_messages show LIA has just offered two slots
- the new inbound text clearly contains a specific time ("11:00am")

The engine should:

- Classify this as the customer choosing a slot.
- Use a T3_APPOINTMENT_SLOT_CONFIRMED / equivalent template, NOT an EOT intro.
- Reply with something like:
  "No problem, LiaTest – let's go with 11:00am at Lincoln Audi. We'll run through your agreement and look at options on the day. If you need to change it, just drop me a message."

TECHNICAL BEHAVIOUR REQUEST:

Please update the URE / rules so that when ALL of these are true:

- appointment_status = "INVITED"
- tier is in the T3_APPOINTMENT family
- recent_messages include an appointment invite or time options from LIA
- the latest inbound message from the customer contains a clear time expression
  (e.g. matches HH:MM, HHam/pm, "11am", "half 9", “about 10:30”, etc.)

…then the state transitions to a "slot chosen" mode, and LIA is forced onto the appointment confirmation template (T3_APPOINTMENT_SLOT_CONFIRMED or equivalent) instead of re-using the generic EOT intro / T1 general.

Key requirements:
- Do NOT change any DB fields from the LLM side – the state machine should handle appointment_status updates as it already does.
- The reply content must stay within the appointment-confirmation lane – short, clear confirmation, no re-selling.
- Maintain all existing safety rules (no figures, no guarantees).

Once this is wired, I’ll re-test by:
1) Triggering the 12-month outbound.
2) Replying with a vague time → see options.
3) Replying with “How about 11:00am?” and confirm that:
   - the reply is a pure confirmation, not another intro
   - the mode/template_key reflects an appointment confirmation path.