Fix non-ASCII characters breaking unquoted names and sheet names

[gthb]

What

Fix three ways an unquoted name or sheet name lexes wrongly when it contains a character at or above U+00B4 (´), where the lexer's table of per-character allow-masks ends. The few non-ASCII characters below that, U+00A1 through U+00B3, already lexed correctly.

• A sheet name starting with such a character swallowed the rest of the reference: =Ærið!A1 lexed as a single range_named token holding Ærið!A1, a defined name, rather than as a sheet prefix, a ! and a range. =Ærið:Ärger!A1 went the same way.
• A name starting with an ASCII character broke at its first such character: =Forudsætninger!A1 came back as Foruds followed by a separate ætninger!A1.
• U+00B4 (´) was refused outright, though U+00B3 just below it and U+00B5 just above it are both legal in a name: it could not start one (=´!A1 lexed as an unknown token) and it ended one that it stood inside (=a´!A1 likewise came back as an unknown token).

Downstream, parse threw Invalid syntax on =SUM(Ærið!A1:B2) and Unexpected unknown token on =´!A1, and gave =Ærið!A1 a ReferenceIdentifier with kind: 'name' where kind: 'range' was meant, leaving a consumer to look up a defined name called Ærið!A1.

Cause

lexNameFuncCntx reads a per-character allow-mask out of ALLOWED, falling back to OK_HIGHCHAR for characters past the table's end. That one expression has two separate faults.

The continuation loop's s > 180 ? OK_HIGHCHAR : ALLOWED[c - OFFS] tests the token's first character s but indexes with the current character c. Once a name started with a high character, every character after it took the OK_HIGHCHAR branch (! included), so the loop never stopped. Where the first character was not a high one, the same expression failed the other way: the lookup ran off the end of the table for a high character, read undefined, and ended the token there.

ALLOWED has one entry per code point from U+0020 through U+00B3, and the guard admitted only code units above U+00B4, leaving U+00B4 itself in neither. It is allowed in exactly the positions OK_HIGHCHAR encodes, so the boundary belongs at U+00B4, not past it.

Fix

Read the mask off c, and move the cut-off to >= 180 in both the loop and the first-character test above it: three changes over two lines, each pinned by a test that fails without it.

Compatibility

Lexing changes only for input containing a code unit at or above U+00B4, which is now treated uniformly as a name and context character, as the character classes commented beside the code call for. A sweep of every UTF-16 code unit across a dozen syntactic positions found nothing below U+00B4 that changes, and no input that gains an unknown token. Consumers that switch on token type will see range_named become range (or context + ! + range) for such sheet references, and a name with a high character in it arrive as one token rather than two.