fix(array_to_sentence_string): coerce non-array input with toArray

[josefguenther]

array_to_sentence_string reads .length and .slice on its input directly (src/filters/string.ts:226), so anything that isn't an array fails the whole render. {{ v | array_to_sentence_string }}:

v	master	this PR
nil	RenderError: Cannot read properties of undefined (reading 'length')	``
5	RenderError: array.slice is not a function	5
"abc"	RenderError: array.slice(...).join is not a function	abc
"ab"	a and b	ab
["a", "b", "c"]	a, b, and c	same

This coerces the input with toArray, as the other array filters do, so nil renders an empty string and a non-array value is treated as a single item. Array input is unchanged.

The two new tests in test/integration/filters/string.spec.ts fail on master and pass here. npm run build, npm test (1674 tests) and npm run lint pass on Node 24.11.1.

Fixes #964

Written with AI assistance (Claude Code); I have reviewed the change.

[harttle]

This filter comes from Jekyll and I find Jekyll also throws for these cases thus it should be left that way. Unless you find otherwise, I'm closing this one.

[josefguenther]

Thanks for checking. Jekyll's version just calls .length without a check, so I read its throw as a missing guard rather than a choice, and LiquidJS doesn't follow Jekyll there in its other Jekyll filters:

• number_of_words has the same unguarded input.split in Jekyll and raises on nil or a number, while LiquidJS renders 0 and 1.
• slugify and cgi_escape raise on a number in Jekyll (cgi_escape on nil too), while LiquidJS renders it as text.
• date_to_string, date_to_long_string, date_to_rfc822 and date_to_xmlschema raise InvalidDateError in Jekyll on a string that isn't a date, while LiquidJS renders the input as written.
• group_by and find raise in Jekyll on an array holding items that aren't hashes, while LiquidJS returns a result.

Of the 24 Jekyll filters LiquidJS ports, array_to_sentence_string is the only one that throws on ordinary non-array input. Jekyll also renders with render! at build time, where a raise stops the author's build rather than a page someone is viewing. So I'd still suggest toArray here, as LiquidJS's other ported Jekyll and array filters do, but it's your call.