feat: allocate IOL Docker application IDs from a pool disjoint from IOU

IOL interface MACs derive from the application ID (aabb.cc{app}{iface}),
so ids must be unique across opened projects sharing computes — the same
reason IOU has its allocator. IOL Docker nodes draw from the upper half
(512-1022, netiomux's fixed peer is 1023) so the two node types can
neither collide nor starve each other; IOU behavior is unchanged.

The controller sniffs the same GNS3_IOL_RUNNER environment marker the
compute uses to select IOLDockerVM (both the nested-properties and
template/top-level-kwarg shapes), stores the id in node properties like
IOU does, and passes it through the Docker create payload. Without an
allocation the compute falls back to a stable node-derived id in the
same upper range.

docs/features/iol-runner-docker.md

@@ -138,9 +138,13 @@ diagnosing wiring issues).
   + ~512 MB headroom or the OOM-killer will shoot the router.
 * **MAC addresses**: the `mac_address` template field and per-adapter custom
   MACs are ignored — IOL derives its own scheme from the node's application
-  ID (`aabb.cc{app}{iface}`), e.g. `aabb.cc03.0400`. The ID is derived from
-  the node UUID so linked routers always get distinct MACs (nodes sharing an
-  ID would silently drop each other's frames as MAC loops).
+  ID (`aabb.cc{app}{iface}`), e.g. `aabb.cc03.0400`. The controller
+  allocates the ID at node creation from the upper half of the id space
+  (512–1022, disjoint from IOU's 1–511, limit 511 IOL Docker nodes across
+  opened projects sharing computes); without an allocation (raw compute API,
+  pre-allocation topologies) a stable node-derived fallback in the same
+  range is used. Nodes sharing an ID would silently drop each other's
+  frames as MAC loops.
 * **Interface names are IOL-style `Ethernet0/0`**, not `GigabitEthernet0/0`
   (4 ports per unit, matching the adapter-count granularity) — startup
   configs addressing `GigabitEthernet…` are rejected by the parser.