Rethink handling of rounding since LuaJIT changed gears

[alerque]

LuaJIT recently (Dec 2025) fixed the way they handle rounding floats: LuaJIT/LuaJIT#1363

This is a good fix, but it creates a bifurcation in what we can expect out in the wild where interpreter deployments vary widely by version. It also potentially breaks our hack here:

sile/core/utilities/init.lua

Lines 435 to 454 in 593ca77

	--- Round and normalize a number for debugging.
	-- LuaJIT 2.1 betas (and inheritors such as OpenResty and Moonjit) are biased
	-- towards rounding 0.5 up to 1, all other Lua interpreters are biased
	-- towards rounding such floating point numbers down. This hack shaves off
	-- just enough to fix the bias so our test suite works across interpreters.
	-- Note that even a true rounding function here will fail because the bias is
	-- inherent to the floating point type. Also note we are erroring in favor of
	-- the *less* common option because the LuaJIT VMS are hopelessly broken
	-- whereas normal LUA VMs can be cooerced.
	-- @tparam number input Input value.
	-- @treturn string Four-digit precision foating point.
	function utilities.debug_round (input)
	if input > 0 then
	input = input + 0.00000000000001
	end
	if input < 0 then
	input = input - 0.00000000000001
	end
	return string.format("%.4f", input)
	end

I'm not sure the new LuaJIT versions will respond the same way to this work around as we expected PUC Lua to do.

Either way the whole snafu needs review to make sure we're doing something sane.