fix(ui): calculator polish — smart input steps, unified tech/MAT lock idiom, tech floor, speed-lock ceiling fix

- pkg/calc: DriveForSpeed treats restMass==0 as a valid ceiling-only
  case (every positive drive solves it), so locking the displayed
  speed of a D=1, W=A=S=C=0 ship is no longer a phantom "infeasible".
- ship-design-area: drive/weapons/shields/cargo inputs use a JS-driven
  smart step on ArrowUp/ArrowDown (0↔1 jump, otherwise ±0.1) and hide
  the native spinner so it cannot produce invalid (0, 1) values;
  armament keeps its native step 1.
- Tech and planet MAT cells follow the same lock idiom as goal-seek
  locks: open padlock (🔓) over the inherited value → click to open
  an input with a closed padlock (🔒). The padlock slot is always
  reserved, so the column width is stable.
- Tech overrides (design area and modernization target) are floored
  at the player's current tech on this turn — a lower value is
  flagged as invalid.

ui/frontend/tests/calc-model.test.ts

@@ -135,6 +135,25 @@ describe("computeCalculator goal-seek", () => {
 		expect(result.blocks.drive).toBe(10);
 	});
 
+	test("speed lock is feasible at the ceiling when rest mass is zero", () => {
+		// Regression for the D=1, W=A=S=C=0 case: every block except
+		// drive is zero, so speed equals 20*driveTech (the ceiling); the
+		// solver must accept that exact target instead of flagging it
+		// as unreachable.
+		const core = makeFakeCore();
+		const result = computeCalculator(
+			input({
+				blocks: { drive: 1, armament: 0, weapons: 0, shields: 0, cargo: 0 },
+				driveTech: 1,
+				lock: { output: "speedEmpty", value: 20 },
+			}),
+			core,
+		);
+		expect(result.lockFeasible).toBe(true);
+		expect(result.computedInput).toBe("drive");
+		expect(result.outputs?.speedEmpty).toBeCloseTo(20, 9);
+	});
+
 	test("calls the matching solver with the right context", () => {
 		const weaponsForAttack = vi.fn(() => 7);
 		const core = makeFakeCore({ weaponsForAttack });