[js] find_elements TypeScript atom: four locator edge cases differ from the Closure locators #18177

The TypeScript find_elements atom (javascript/atoms/typescript/core/locators.ts, on trunk since d9cc9ea in find-elements.ts) differs from the Closure locators in four edge cases. Raised by review on #18175, which moved this code but did not change it. Fixing it changes the find_elements atom that every binding injects, so it needs its own PR.

1. Link text with  . getLinkText compares innerText after trimming but never maps U+00A0 to a space, so an exact search for A B misses a link rendered as A B. Closure's bot.dom.getVisibleText normalised it, so this is a regression from the earlier migration. Normalise   to a space before exact and partial comparisons.
2. name containing a newline or other control character. nameMany/nameSingle put the value into a quoted CSS attribute selector, escaping only " and \. A raw newline makes the selector invalid and the lookup throws. Escape with CSS.escape, or compare getAttribute('name') directly.
3. id containing a newline or other whitespace. cssEscapeId prefixes whitespace with a backslash, which is not a valid CSS escape for a newline, so idSingle returns null and idMany returns []. Use CSS.escape.
4. Relative-locator anchor when a root is supplied. resolveAnchor searches the caller's root before the document, so if a locator matches an anchor both inside and outside the root, a scoped search measures from the inner one where Closure used the document's first match. This is deliberate (an anchor inside a shadow root is invisible to a document search), but it should be documented and pinned by a test rather than left implicit.

Each fix should come with a case in javascript/atoms/test/find_elements_typescript_test.html (or the relative-locator page) that fails first.