test: take the lab management prefix from the environment

[BSpendlove]

Problem

Every integration topology hard-codes its management subnet under 172.20.0.0/16: 34 suites share clab on 172.20.20.0/24 and 19 keep a suite-private network on a distinct third octet. On a box where another Docker network already owns 172.20.0.0/16, containerlab refuses to create the management network and no suite can deploy. The only way to run the rig there was to edit 53 topology files or copy suites aside, which is how the #505 verification had to be done.

Change

The /16 comes from the environment for the 34 suites on the shared clab network: ipv4-subnet: ${OSVBNG_LAB_MGMT_PREFIX:=172.20}.20.0/24. The 19 suites with a private management network keep their literal 172.20 subnet on purpose: they pin each node's mgmt-ipv4, and their bind-mounted RADIUS, Kea and robot files name those addresses, which containerlab does not expand. Moving only their subnet leaves the node outside its own network and containerlab deploy hangs, which the first version of this change did and a local sweep caught; the second commit reverts those 19 topologies and the docs say why. common.robot carries the variable through sudo --preserve-env beside the core-slot variables, and the topology invariant in docs/contributing/ci-and-review.md documents it. Unset, every file expands to exactly what it said before, so the CI runner (which pre-creates clab on 172.20.20.0/24) is unaffected.

Verification

On a box with 172.20.0.0/16 taken: OSVBNG_LAB_MGMT_PREFIX=172.31 runs the shared-network suites from #505's verification (53, 24, 08, 10 and the sweep recorded there) on 172.31.20.0/24. With the variable unset, git diff against main is the one line per shared-network topology and nothing else changes. The private-network suites were not runnable on that box before this change and are not after it; they run on the CI runner, where 172.20 is free.