feat: apply nonlinear/asymmetric T200 thrust curve in manager + sim

[nrebolloso]

Closes #340.

The thruster manager assumed thrust maps linearly to effort and that a thruster makes the same force forward and reverse. Neither is true for the T200s (forward is ~20-30% stronger than reverse, and the PWM-to-thrust curve is nonlinear), which is likely behind the asymmetric rotation and the flaky translation maneuvers, plus why anything that trusts the thrust estimate (open-loop control, drag comp) only works sometimes.
This replaces the old single-slope scaling with the real measured curve, and makes the sim use the same one.

1. Shared thrust curve in lut.h. The measured T200 curve, transcribed from the thruster board ("purple board") and converted from kgf to Newtons. 201 samples evenly spaced in effort from -1.0 (full reverse, -39.9130655 N) to +1.0 (full forward, +51.4849125 N), so full forward is ~29% stronger than full reverse. |effort| <= 0.07 is the deadband and produces 0 N. Two directions: force_from_effort and effort_from_force, both linear-interpolating the same table.
2. Manager uses the curve in reverse. It takes the per-thruster force it wants (from the allocation pseudo-inverse) and looks up the effort that produces that force, instead of dividing by a single max. I removed the old max_force_pos/max_force_neg scaling, the direction-dependent max thrust is already baked into the curve, so keeping both would double up.
3. Saturation moved into force units. The thruster_cap is converted once to the forward/reverse force limits it implies, and if any thruster exceeds its limit every force is scaled down by one factor. Saturating in force (before the curve) instead of in effort keeps the wrench direction correct, since the curve is nonlinear and scaling efforts would distort the relative thrust mix.
4. Sim applies the same curve. The Gazebo ThrusterBridge reads the same /thruster_efforts and runs force_from_effort to get the force it applies to the plant. Manager and sim now share one thrust model, so the sim thrusters behave like the real ones and the command path is identical.
5. Documented the curve. README and lut.h now say exactly what it is (measured T200, Newtons, 201 points, endpoints, deadband, asymmetry) instead of "took it from the purple board."

Testing:

Added test/test_lut.cpp (GTest, wired into CMake):

• Endpoints match the table; effort and force both clamp out of range.
• Zero maps to zero both ways (deadband).
• force_from_effort is monotonic in effort.
• effort_from_force inverts force_from_effort (round-trip, skipping the
  deadband where the inverse isn't unique).
• Forward is stronger than reverse at equal effort magnitude; reaching a given
  force in reverse costs more effort than forward.
• Commanded-force survives the full manager -> /thruster_efforts -> sim round trip exactly (both ends interpolate the same table).

All 11 passing. Writing these caught a small out-of-bounds bug in the interpolation at the top of the range, now fixed.
Validated in sim: applied the curve in Gazebo and the thrusters respond with the asymmetric force. Not yet validated on hardware.
Two things to flag for review:

• Direction. The curve assumes a positive command is each thruster's stronger (forward) direction, but the T200s mix CW/CCW props, so on some thrusters a positive command might actually be the weak direction, which would apply the asymmetry backwards. If someone can confirm the spin directions per thruster we can make sure the curve is applied the right way. Noted as an assumption in lut.h.
• Voltage. The table is for a single supply voltage (~16V). The sub runs ~15.5-16V, which shifts max thrust a few percent. I looked into inferring voltage and there's nothing in software that reports it, the board only sends a battery-low flag, so this feels like firmware. Since it's only a few percent at full throttle, I'd suggest deferring voltage-aware curve selection to a separate issue.