fix(translate): answer blank texts with themselves instead of failing the request

[JounQin]

Fixes #244. Nothing about emptiness is an error now: every text is answered — translated when it carries something, returned as it arrived when it is blank — and an empty list is answered with an empty list.

A request used to fail as a whole when any one of its texts was empty, so a document split into lines could not be translated at all if it had a blank line in it. The rule was inconsistent too — "" failed the whole request while whitespace-only passed through, because whitespace survived only as a side effect of oneshot echoing it back.

request	before	after
["", "Hello"]	404 No text to translate	200 ["", "你好"]
["Hello", ""]	404	200 ["你好", ""]
["", " "]	404	200 ["", " "]
" ", [" "]	200, whitespace sent upstream	200, answered locally
"", [""], ["", ""]	404	200, texts echoed back
"text": []	404 No text to translate	200 {"data": []} — the request is mirrored
null text	404, then 200 "" on this branch	400 Invalid request payload — a null text names no text
no text field	404 No text to translate	400 Invalid request payload

A null text is the same case as a missing one, and it used to be the opposite one. json.Unmarshal into a string is a documented no-op for null, so {"text":null} decoded to [""] and was indistinguishable from {"text":""} for the rest of the request: 404 on main, and 200 "" on this branch, which nobody asked for. UnmarshalJSON now leaves the zero value for null, so Texts == nil means "the request named no text" — the key is missing or null — and the handler tests exactly that instead of re-deriving the decoder with !Batch && len(Texts) == 0.

The refusals left are therefore a body that never named text and a null one: in both cases the request carries no text, which is a payload without its parameter rather than an empty text, and it is the same 400 the endpoint already answers for a body it cannot bind. "text": [] is not that case: it names a list that happens to be empty, and the response renders it perfectly well.

Forwarding a blank cannot work: oneshot echoes an empty input, and the positional all-or-nothing check reads that echo as a failed translation, so the answer becomes 503 Translation failed. Measured live on 83f97d3 with only the empty-element guard removed, ["", "Hello"] and ["Hello", ""] both answer that 503. The bypass therefore happens here.

Change

• totalTextLength(texts) becomes textsToTranslate(texts) (positions []int, total int): a blank text is skipped and not charged against the cap, and the zero-text request leaves both empty.
• TranslateByDLX answers every request: the texts that carry something travel upstream, and mergeTranslations splices the answers back with every blank text left exactly as it arrived. When there is nothing to send, the same call returns the texts unchanged — allocated, so an empty request marshals as [] and not null.
• PayloadText.UnmarshalJSON leaves its zero value for a null text, so Texts == nil covers both ways of naming no text, and the /translate handler refuses that with 400 Invalid request payload before translating. Any other request mirrors the shape it was given.
• Tests: textsToTranslate positions and length; pure mergeTranslations; TranslateByDLX answering nil, [], "", [""], ["", ""], whitespace and ["", " "] with themselves; decode tests pinning null and the missing key to a nil Texts against "text": []'s allocated empty slice; handler-level tests for the "data":[] / "data":"" shapes and the no-text 400; and the cap cases on the reduced payload.
• The README documents the rule.

This matches the JavaScript client (@deeplx/core batchPayload and restoreBlankSegments), which already drops text.trim() === '' segments and restores them.

go build ./..., go vet ./... and go test ./... pass. Live on a build of this branch: ["", "Hello"], ["Hello", ""], ["", " "], [" "], [" ", "Hello"], "", [""], ["", ""] and {"text":[]} all answer 200 with data in the shape the caller used; a body with no text, or "text": null, answers 400 Invalid request payload; ["", "😀"×751] answers 413 text exceeds maximum length: 1502 characters and ["😀"×400, "", "😀"×400] answers 413 … 1600 characters, so blanks are not charged against the cap.

Refs #240, #241.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.