Issue #3614440: Rename the deposit vocabulary to guarantee, and let one guarantee cover the deposit and the no-show fee

One word for the money a booking holds against a card, and one amount covering both things it can turn into.

The rename. The resource fields caution_enabled / caution_amount / caution_mode become guarantee_*; noshow_fee keeps its name, because it is the fee and not the guarantee. The workflow actions, their labels, the process variables (yoyaku_guarantee_outcome, yoyaku_guarantee_amount), the variable provider, the config schema keys, the example workflow's node and flow ids and labels, the docs and the French translation all follow.

The part that is not a rename. A guarantee now covers both endings, so its amount is the larger of what a damage claim may take and what a no-show costs: only one of the two can happen, since a visitor who never arrived cannot also have damaged anything. A no-show is therefore a claim on the guarantee rather than a fresh charge against the stored card, which is far likelier to succeed. chargeToken() leaves yoyaku entirely, and with no second guarantee payment, settlement keeps answering for the checkout payment alone.

The rule is mode-aware, and deliberately so. A held guarantee is sized to the larger claim, because a hold is not money taken and sizing it to the worst case costs the payer nothing. A charged guarantee collects only what the resource asked for: the payer really is out of pocket from the start there, so a fee larger than the guarantee must not quietly raise what the checkout takes, and a no-show claims what is in hand.

One ending, three exits. Every ending asks the same question, so they share one answer in BookingPaymentActionBase::endGuarantee(): how much does the site keep? Nothing on a good outcome, the damage claim, or the no-show fee. Each exit then works in either mode, because a workflow branches on how the stay went and not on how a resource is configured: a held guarantee is claimed for what is kept (closing the hold so the provider frees the rest), and a charged one has the difference refunded out of the checkout payment, leaving the price captured. That also fixes a claim against a charge-mode guarantee doing nothing at all, which is what the damage step did before.

Claims carry their reason (damage or no_show) into kessai's claim rows from #3614985, so two endings that move the same total stay legible apart.

Also here: the example workflow's no-show path now ends at the terminal, since a claim closes the hold itself and there is nothing left to release; the stale note about kessai's cancel() taking no amount is gone; and docs/deposits.md becomes docs/payment-windows.md, because that page is about advance payments (the form window, then the payment window) rather than about guarantees, while deposit-gateway-design.md becomes guarantee-gateway-design.md and its "two instruments, never merged" section is replaced by "one guarantee, two ways it can be claimed".

Supersedes the no-show half of #3614433. Pre-1.0 and reinstall-only, so no update hook; the resource fields are renamed, which is a release-note line.

Depends on kessai #3614985 (MR !43 (merged)) for the kind on capture(). Until that reaches kessai 1.x-dev, the pipeline here fails.

Tests: GuaranteeReturnTest covers the two new endings in both modes and that a no-show leaves one guarantee payment rather than a second charged one; PaymentPolicyResolverTest pins the fee-only line taking a held guarantee, the larger-claim rule, and a charged guarantee ignoring a larger fee. Both were watched failing against the unfixed behavior first.