Fix condition check for selectionInfo.start

[desvaters]

Description

After a swap that replaces the focused element, htmx restores focus by id and is meant to restore the selection too, but the check

if (selectionInfo.start && newActiveElt.setSelectionRange) {

treats selectionStart === 0 as "no selection". A fully selected value always starts at 0. That's exactly what you get when you Tab into a text input, so it is never restored.

Common trigger: an input with hx-trigger="change" whose response re-renders the next field. Leaving the first field via Tab fires change, the swap recreates the field you just tabbed into, and its selection is lost.

Fix:

if (selectionInfo.start != null && newActiveElt.setSelectionRange) {

!= null still skips elements without text selection (null) and elements without the property (undefined). This matches the condition the 4.x rewrite already uses in __setFocus.

Corresponding issue: none for this case specifically; related to #343 (where selection restoring was introduced).

Testing

Tested manually in Chromium: an input saving on change, with a response that replaces the next input by outerHTML / out-of-band swap. Before: after Tab, the next field is focused with selection 0–0. After: the full selection (0–length) survives the swap, and typing replaces the value. Partial selections starting at a non-zero offset behave as before. No new automated test added.

Checklist

• I have read the contribution guidelines
• I have targeted this PR against the correct branch (master for website changes, dev for
  source changes)
• This is either a bugfix, a documentation update, or a new feature that has been explicitly
  approved via an issue
• I ran the test suite locally (npm run test) and verified that it succeeded