decision: move off the fixed 9100 port base

[mobileskyfi]

The decision

Whether to move off the fixed 9100 port base to reduce cross-instance collisions, and
if so, how.

Options

• Random high-range base per machine — clean, but changes the persisted port contract.
• Setting-with-default — keep 9100 as the default, allow an override. Smaller blast
  radius.
• Status quo — document the collision risk only.

Recommended default

Setting-with-default first (non-breaking), with a clean high range chosen for the random
path later. Rationale in DESIGN.md "Port Layout → Allocation rationale".

What it changes

The port-block layout — persisted, and relied on by first-party consumers. Needs the
migration/coordination note per DESIGN's compat caveat. Coordinate with the
service-block-redesign decision (same contract).

Done-when

Direction recorded here; if "move", a Task is filed with the migration sketch; else
closed with the rationale.

[mobileskyfi]

At some point, I had an agent look for undefined port ranges in regisered IANA services. Here is what I know:

1. 8810-8872: 63 ports # likely the new base to start
2. 8504-8553: 50 ports
3. 8616-8664: 49 ports
4. 9451-9499: 49 ports
5. 9763-9799: 37 ports
6. 9701-9746: 46 ports
7. 6717-6766: 50 ports
8. 5915-5962: 48 ports
9. 9803-9874: 72 ports # reserved for other TIKOCI project

So I think that be order to use as above. Unless I'm missing something common.
e.g. I didn't not cross-reference some common application/protocol that uses a port NOT registered in IANA.

[mobileskyfi]

I think most of the consumers at this point are other tikoci project. And I'd imagine most have coded in to read their actual port assignments. Since while 9100 is starting, spinning up machines quickly get different ports so user should always check the ports returned anyway... so less concerned about the blast radius on that one. I think we already allow custom port assignments, if not we should include that as part this work, since a caller may already know the port they want to use themselves.

[mobileskyfi]

We should consider both #57 and this issue (#56) together. At least for planning purposes so there is some agreed scheme to resolve #57, with eye toward this one in that work.