lots of linter fixes

[oliviaBahr]

Make the linter happy :)

[Brawmario]

My two cents:

• These new global_table = global_table or nil lines makes no sense to me. nil is already the default value that a Lua symbol will evaluate to if it's not defined, so adding these lines are a no-op as far as the semantics of the language are concerned. Worst case scenario these symbols are actually holding a boolean false value instead, in which case you're just "deleting" that value.
• Silently returning from a function just because a table we expected to be valid is nil can be problematic. Sure, we avoid a crash by avoiding to deference a nil symbol, but this can cause bugs that will be much harder to debug, since this can cause the program to malfunction much later, and then it will be difficult to link that malfunction to the root cause. Sometimes it's for the best that the program crashes spectacularly when it should, since at least the source of the bug becomes obvious. At the very least we should definitely log any table that is nil when it should exist.

Overall, we have to ask ourselves "WHY is the linter unhappy" and not just attempt to appease it at any cost.

[stephenkirk]

Took a bit to reverse-engineer what linter this is defending against — it's LuaLS (Lua Language Server). The ---@diagnostic disable-line comments gave it away.

The X = X or nil pattern is a no-op that just tells LuaLS "yes, this global exists." The proper fix is a .luarc.json at the project root with a diagnostics.globals list for cross-mod symbols (Distro, Handy, TMJ, Galdur, Talisman, Wheel, etc.). That would eliminate most of these changes outright.

Agreeing with Brawmario's points — the silent nil guards (if not X then return end) are a separate concern from linter happiness and can mask real bugs downstream.

Happy to get a .luarc.json set up. Ping me on Discord (stephylicious) if you want to go over directions for that or anything else here.