firestore-translate-text: a null input on update errors and leaves stale translations instead of clearing them, in both extension and kit

[cabljac]

Setting the input field to null on an existing document is the one "no text here" value that neither clears the translations nor gets skipped. It errors out and leaves the previous translations in place, in both the extension and the kit.

handleUpdateDocument clears the output field when the new input cannot be translated:

if (typeof inputAfter !== "string" && typeof inputAfter !== "object") {
  await updateTranslations(after, FieldValue.delete());
  return;
}

typeof null is "object", so null passes this check and falls through to translateDocument. Removing the field (undefined) or setting a number both hit the branch and clear translated; null does not.

Extension (firestore-translate-text/functions/src/index.ts:236, translate/translateDocument.ts:66): null routes into translateMultiple, Object.entries(null) throws TypeError, the handler catch logs it and records an error event. Nothing is written, so the stale translated map stays on the document.

Kit (kits/firestore-translate-text/src/handlers.ts:147): same check, same fall-through. Routing parity with the extension is restored under #3142, so the failure is identical.

Only reachable on update; create is guarded by if (input).

Proposed fix, one change across both codebases so they keep producing the same output for the same document: treat null as removed input in the delete branch.

if (
  inputAfter === null ||
  (typeof inputAfter !== "string" && typeof inputAfter !== "object")
) {

Plus one handler test: before input: "hello", after input: null, expect updateTranslations called with FieldValue.delete() and no translation call. Behaviour change for the extension too (error becomes clear), so it needs a CHANGELOG entry on both sides.

Split out of #3142, where the ruling was parity for the routing. Parity ledger: #2974, firestore-translate-text §4a.