fix: emit bxor, not bnot, for binary '~' with --gen-target 5.1

[dylanpulver]

~ is both unary bitwise NOT and binary bitwise XOR, but the 5.1 compat pass in teal/gen/lua_compat.tl matches on the operator token alone, so the unary branch swallows the binary one.

local function f(a: integer, b: integer): integer
   return a ~ b
end

tl gen --gen-target 5.1 before / after:

   return bit32.bnot(a)     -- before
   return bit32.bxor(a, b)  -- after

The right operand is dropped and the operation changes, silently: the checker accepts it as integer and the output is still valid Lua. &, |, << and >> are all correct; ~ is the only one of the five with a same-token unary form. The metamethod path splits the same way, sending a ~ b on a record with __bxor to __bnot with one argument.

The fix is an arity check, so binary ~ falls through to the existing bit_operators branch, which already maps ~ to bxor and __bxor.

Also spec/util.lua: gen() built its line arrays with gmatch("([^\n]*)\n"), which drops the final line, so a util.gen mismatch confined to the last line of the output was never reported. That is why the metamethod half stayed invisible, and why the existing __bnot metamethod test cannot catch a regression either. With \n? the suite is unchanged at 1941 passing, but both halves of this bug now fail it.

Regenerated the .lua artifacts with make.

Drafted with AI assistance (Claude Opus 5).

[hishamhm]

LGTM! Thank you, good catch!