[nickolasdeluca]

Found while testing #11 against a local deployment.

The TCP port range lives in the server config and the reservation lives in SQLite, and nothing connected the two. The panel wrote whatever port it was given, and the deployment only disagreed later, when a client registered:

registration_failed - failed to allocate requested port 20052: requested port 20052 outside range 33000-33020

From the panel's side the allocation looked fine, so the failure reads as the allocation having been lost rather than as a port that was never valid in the first place.

The fix

• admin.Deployment carries TCPPortMin/TCPPortMax, filled from the server config.
• checkTCPPortRange guards both paths that write a reservation — handleCreateReservation and the Patch in builder.
• The builder checks before resolving the allocation, so an out-of-range port is refused whether it would be created or adopted from an earlier reservation. A command promising an address the server cannot serve is worse than no command.
• /api/server reports the range, so both port fields carry it as their min/max and the browser stops an out-of-range value at the control.

Deliberately left alone

• A deployment that reports no range refuses nothing. Both bounds zero means the server did not say, and refusing an allocation over information it never gave would be worse than the symptom being fixed.
• Pinning a live session is not checked. Its port came from the allocator, so it cannot be out of range.
• drip admin reservation create still knows no range. It writes straight to the database — this is how the out-of-range rows in my test deployment got there. Closing that would mean teaching the CLI to read the server config, which is a separate decision. Recorded in AGENTS.md.

Testing

6 new tests: refusal and acceptance on both paths, the no-range escape hatch, refusing to adopt an out-of-range allocation, and /api/server reporting the range. go vet and go test -race ./... clean.

Checked in the panel too: the port placeholder becomes the server's actual minimum, and submitting a port outside the range is stopped at the field before it reaches the API — which refuses it as well.