Document warm-transfer-experimental fallback, custom summary, and operator-hold behavior

[Mehayla]

Adds fern/calls/assistant-based-warm-transfer-fallback-and-summary.mdx, documenting warm-transfer-experimental fallback-message behavior on a failed transfer, summaryPlan.customLlmUrl, and prompting guidance to prevent the transfer assistant from completing a transfer into an IVR/hold queue.

Follow-up needed before this page is reachable: this PR intentionally does not touch fern/docs.yml. Add a navigation entry for this page (e.g. alongside the existing Assistant-based warm transfer entries) so it builds and appears in the sidebar.

[Mehayla]

Why this page, and why now

Weekly customer-feedback review (support tickets, Ask AI conversations, Discord, NPS) for the most recent complete data window (Aug 22–Aug 28; the Ask AI source lags ~10 days behind wall-clock, so this is the latest complete week available, not the calendar-current week).

• The Default Tools topic was the top topic this week (140 conversations), up from 103 the prior week and above its trailing 4-week weekly average (~126), i.e. a sustained climb, not a one-off spike.
• 152 of those conversations (~63%) are tagged to the Transfer Call tool specifically, concentrated in themes like "Warm Transfer Behaviors & TransferPlan Modes" (37), "Call Handoff & Transfer Failures" (27), "Transfer Tool Configuration & QA Setup" (40), and "Warm Transfer Setup & Timing Questions" (25) — the same small set of warm-transfer-experimental scenarios recurring across multiple distinct customers, not a single account's issue.
• docs.vapi.ai/tools/transfer-call, .../tools/transfer-call/warm-transfer, and .../calls/assistant-based-warm-transfer all exist and are on-topic, but none of them document: (1) what should happen when a warm-transfer-experimental transfer fails (fallbackPlan.message vs. summaryPlan precedence), (2) summaryPlan.customLlmUrl, or (3) how to prompt the transfer assistant to recognize an IVR/hold-queue response instead of a live operator. This is an incomplete content gap on an existing, correctly-scoped page family, not a missing feature area.

Customer evidence

"...we found a reproducible bug on a transferCall tool using warm-transfer-experimental. When a transfer to an unreachable or unanswered number fails, the assistant does not speak the configured fallbackPlan.message. Instead it reads the summaryPlan content out loud to the caller ... and the call ends with endedReason call.in-progress.error-transfer-failed instead of finishing cleanly."
— Moritz Lindner, Bitbasegroup (support ticket)

"...our server never receives any request. The actual summary generation appears to use Vapi's internal model instead... Does customLlmUrl work with warm-transfer-say-summary, warm-transfer-wait-for-operator-to-speak-first-and-then-say-summary, and warm-transfer-experimental?"
— Quan Li, Myflashcloud (support ticket)

A third distinct customer separately asked why a warm transfer ended with call.forwarding.operator-busy after the destination said "please hold for the next available representative," expecting the transfer assistant to recognize that as a non-human response rather than complete the transfer — the third scenario this page addresses.

Why fern/docs.yml isn't touched in this PR

This run's tooling could not retrieve a byte-exact copy of fern/docs.yml (or of the existing .mdx pages) to safely rewrite it — file-content reads in this environment return only a success confirmation, not literal content, and a blind reconstruction of a 50KB nav file risks breaking the site build. The new page is additive only (no existing file touched). It needs one navigation entry added under the existing Assistant-based warm transfer entries in fern/docs.yml (there are two, in two different nav sections) before it will build and appear in the sidebar — flagging this explicitly rather than guessing.

Opened from a fork (Mehayla/docs) since the connected GitHub identity doesn't have push access to VapiAI/docs.