decision: fixed service-block redesign (Windows +6..+8 IPC collision)

[mobileskyfi]

The decision

Whether to replace the fixed service-port "block" with a design that avoids the Windows
+6..+8 IPC-offset collision.

Options

• Dynamic variable-size blocks — allocate what each machine needs.
• Fixed core pool + separate extras pool — core services fixed, optional extras
  elsewhere.

Both dodge the Windows +6..+8 collision.

Recommended default

Fixed core pool + separate extras pool — the simplest that removes the collision.
Rationale in DESIGN.md "Port Layout".

What it changes

The port-block layout (persisted). Coordinate with the port-base-randomness decision
(same contract) and the Windows umbrella (the +6..+8 collision is a Windows-IPC fact).

Done-when

Direction recorded; implementation filed as a Task with migration, or closed.

[mobileskyfi]

This is also related to #56. So let's consider the scheme before working on either this #57 or related #56.

I'm okay if we don't allocate sequencatially, or perhaps skip some like +6..+.8 so semi-sequential/"nearby". Although ideally the mgmt ports generally follow same scheme (at least start there) so there is some predictablity in assignment (although not sure exactly how useful that is in practice) but it mildly convientent that quickchr ports are "grouped" together in lsof/netstat/etc.