The wired fallback wasn't up. I had been managing the router over WiFi while believing I was using the cable. That is the mistake I want to remember before touching this configuration again: prove the access path, rather than remembering which path I meant to use.
The intended tagged uplink had another misleading reassurance. The switch reported Trunk mode, but the membership table showed only an untagged VLAN. The label looked right; the membership did not match the plan. Read the table underneath the label.
On the router, bridge-VLAN changes kept rolling back. I checked the access path and the configuration cells, then investigated the firmware and missing bridge utility. I attributed the failure to firmware support, but that investigation wasn't an isolated proof of the cause. I reverted the router changes and checked that nothing remained pending.
Move the routing, not the firmware problem
I deferred the firmware upgrade. The router was the household gateway, and the backup came from the installed release. I didn't want to make that upgrade part of this change.
Instead, I chose to put the VLAN routing interfaces on the switch and leave its uplink to the router untagged. That changed where routing would happen without requiring the router to receive tagged frames. It also gave me a switch rebuild to do.
The mode-change command wasn't in configuration mode. I found it at the privileged prompt by checking the command tree. Remember that detour before pasting the same command into the wrong place again.
More importantly, the warning explicitly said the change would delete the startup configuration and reset the device. This wasn't a setting to flip and carry on. The session disconnected, and afterward SSH had to be enabled again through the web interface. Recovering access was part of the rebuild, not an optional cleanup step.
Check what the device actually has
I restored the base configuration, VLANs and port assignments from the backup, saving between phases. The mode query reported Router, and the added VLAN interfaces appeared as Valid.
Then my planned static default route failed. Looking at the routing table showed a default route already supplied by DHCP, along with forwarding enabled. The useful correction was to inspect what was there instead of repeating a command because the plan said it belonged there. The failed command and existing route didn't, by themselves, prove why the command was refused.
The upstream router also needed return routes for the newly routed networks. I entered those routes in its web interface, then checked that they appeared in the kernel routing table. An entry in the UI and an installed route are different things to verify.
That was still not the client test. I saved the configuration, but DHCP for the new VLANs remained unresolved, end-to-end routing hadn't been tested from a client, and I hadn't configured ACLs. I deliberately left the virtualization host on its original VLAN.
When I come back to this, start with that unfinished work. Router mode, Valid interfaces and installed return routes are useful checkpoints. They aren't a substitute for testing the client path I hadn't yet tested.