Result shows an overlap as a positive distance: "Measured 1 ft 3 in. The rule is 0 in" #40

Seen in device field test run 2: TestFlight build 3.1, beta at ad91620, capture code t3/ios-mvf e9e405d, server e106acb. The exported scan was lost before it was copied off the phone, so this comes from the screen recording and the code at ad91620. Times are in the recording. b7f51ba and 49a676e on t3/ios-mvf don't change this.

What happens. The result's working-space line read: "Clear of the meter's working space / The battery is within
measurement error of the meter's 2 ft 6 in wide by 3 ft 0 in deep working space. Measured 1 ft 3 in. The rule is 0 in,
and the measurement can be off by about 1 ft 6 in."

The spot runs from 2 ft 7 in left of the meter to the meter itself. The server's measured_ft is −1.25, an overlap
of 1 ft 3 in with the working space (solver.py#L583-L587), not 1 ft 3 in of clearance. The line reads as
if the battery clears the rule.

Cause. Distance.feetAndInches treats negative input as its magnitude
(Distance.swift#L7-L9), and the measurement line passes the value straight in
(ScanCopy.swift#L358-L360).

Related to #36 / PR #37 (at least / at most), but a separate bug: the sign is lost before any wording is chosen.

Possible fix. When measured < 0, say "Overlaps by 1 ft 3 in" (or "1 ft 3 in inside"). The same applies to any
clearance check that can go negative.