Add zero-value guards to abaci.sol auction parameter setters

[daatsuka]

In src/abaci.sol, both LinearDecrease.file() and StairstepExponentialDecrease.file() previously accepted zero as a valid value for tau and step respectively. This is a problem because LinearDecrease.price() divides by tau and StairstepExponentialDecrease.price() divides by step — setting either to zero through the admin file() function would cause every subsequent price() call to revert with an unrecoverable division-by-zero, effectively bricking any active auction that depends on these price curves.

The two file() functions now wrap the assignment in a require(... > 0) check so the contract rejects the misconfiguration at the moment it is attempted, rather than silently accepting it and failing later at auction runtime. The error strings follow the existing convention in the codebase (LinearDecrease/tau-is-zero, StairstepExponentialDecrease/step-is-zero) and the cut parameter already had its own upper-bound guard in StairstepExponentialDecrease, so the step guard brings it to parity.

On the test side, src/test/abaci.t.sol gains a small Vm interface to access expectRevert, along with two new test functions — test_linear_decrease_tau_zero_reverts() and test_stairstep_step_zero_reverts() — each deploying a fresh contract instance and confirming that file("tau", 0) and file("step", 0) revert with the expected error message. I ran the full suite locally with forge test and all tests pass cleanly, including the existing test_linear_decrease, test_stairstep_exp_decrease, and test_continuous_exp_decrease cases, so the new guards do not interfere with legitimate parameter values.

Closes #297