schedule_interview

    ASK BEFORE CALLING — DO NOT PICK A ROLE ON YOUR OWN:
    - A role is MANDATORY and now ENFORCED: if you pass neither role_id
      nor a position, this tool schedules NOTHING and returns
      {"status": "role_required", "existingRoles": [...]}. When you get
      that, ask the user which role to use, suggesting the returned
      existingRoles, and only call again once they pick one.
    - If the user did not name a role AND did not give enough info to
      create a new one (position + JD/skills), STOP and ask first.
    - Wrong role = wrong invite goes out. Treat role selection as
      mandatory clarifying input; never default.

    DRY RUN FIRST IF YOU'RE AUTO-FILLING ANYTHING:
    - If you are supplying any field the user did not explicitly state —
      interview_type, position, job_description, evaluation_focus,
      duration, language, required_skills, OR candidates extracted from
      a paste/CV — CALL WITH dry_run=True FIRST.
    - The response returns the normalized candidates + the role payload
      that WOULD be created or used, including the evaluation focus
      split. Persists nothing, sends no email, consumes no quota.
    - Read it back to the user in chat as a brief "here's what I'd send"
      summary (4–6 bullet lines covering candidates, role, interview
      type, focus split, JD if auto-generated). Get explicit go-ahead.
    - THEN call again with dry_run=False to actually send invites.
    - Only skip dry_run when EVERY field came from the user verbatim
      (e.g. they named the role, the interview type, and pasted clean
      structured candidates with no extraction).

    EVALUATION FOCUS HANDLING:
    - If user didn't specify, leave evaluation_focus out — backend
      reuses the existing role's stored split, or applies an
      interview-type default for new roles (screening:
      role-fit/comms/experience/motivation; technical:
      depth/problem-solving/comms/system-design; hr:
      comms/culture/motivation/leadership).
    - The dry-run response surfaces what the resolved split will be so
      the user can override before invites go out.

    CANDIDATE FIELDS:
    - Each candidate dict requires 'firstName' and 'email'. Optional:
      'lastName', 'phoneNumber', 'experience', 'summary'.
    - Email must be well-formed; phone numbers auto-normalise to 10
      digits (Indian format).

    TIMING — IMPORTANT:
    - This tool sends an invite EMAIL. The candidate opens the link
      when they're ready; THEY pick the moment to start the interview.
      You cannot pin an interview to a clock time via this tool.
    - If a user says "schedule Priya for 3pm Tuesday" — explain that
      AIIA invites are candidate-self-served, then offer to send the
      invite now (so Priya has it in her inbox) or note the desired
      window in the candidate summary so HR can chase if she hasn't
      joined by then.

    OTHER:
    - interview_type: 'screening', 'technical', or 'hr'.
    - duration: seconds per interview (default 900 = 15 min).
    - language: 'en', 'hi', or 'ar'.
    - If role_id is provided, position/jobDescription are ignored.

    Returns per-candidate status. Some rows may succeed while others
    fail (invalid email, quota exhausted, duplicate within role). Never
    assume the whole batch succeeded.