fix(calendar): show in-flight state on Save, and surface the silent length-guard rejection

[texchi2]

Follow-up to #888 / #887. That PR fixed the crash in the calendar Save path (crypto.randomUUID
on insecure origins); this one fixes the two places where the same dialog gives the user no
feedback at all, which is what made the crash present as "the Save button is dead".

Both are still reproducible on main today.

1. Save has no in-flight state

handleSave is async, and the button is disabled while isSaving — but nothing on screen
changes. On a slow link (mobile, VPN, a self-hosted server over a tunnel) the button simply stops
responding for the full duration of the request, which reads as a dead button and invites repeat
clicks. disabled prevents the double-submit, so this is a feedback bug rather than a data bug —
but "nothing happened" is the reason users click again.

Fix: {isSaving ? t("form.saving") : t("form.save")}, plus the missing calendar.form.saving
key. (calendar.form had no saving; the saving key that exists elsewhere in common.json is
in a different namespace.)

2. The length guard returns silently

if (trimmedTitle.length > 500 || description.trim().length > 10000 || location.trim().length > 500) return;

A save rejected here produces no toast, no field error, no dialog change — indistinguishable from
case 1. The inputs also enforce these limits via maxLength, so this is a backstop that should
rarely fire; when it does, it should say so. Fix: toast.error(t("notifications.event_error"))
before the return, using the key that already exists.

Notes

• Two files, +12/-2, no refactor, no dependency change.
• notifications.event_error already exists; only calendar.form.saving is added, English only —
  happy to leave it for translators or add other locales if you prefer.
• Found while running Bulwark against a self-hosted Stalwart over a plain-http LAN origin, which is
  also how Create-event dialog reports failure although CalendarEvent/set succeeds (Stalwart 0.16.18) — duplicates on retry #887 surfaced. Happy to adjust the wording or drop the code comments if you'd rather
  keep the file comment-free.