vlan: reject VLAN IDs the table cannot hold

vlan_create() and vlan_delete() wrote the ID straight into the table index
register. vlan_get() has refused anything >= 0xfff for a while, so reads were
guarded and writes were not: "vlan 4095 1 2" built an entry that no read path
can see, and IDs above that either miss the table or alias onto another VLAN.

Both writers now enforce the range vlan_get() already did, and parse_vlan()
rejects the same values with the usage message so the CLI says why. The check
sits after the "vlan 0 mgmt" branch, which legitimately takes 0 to switch the
management VLAN off.

Costs nothing in RAM: rtl837x_port.rel stays at DSEG 0, OSEG 5, and the image
still reports 10207 bytes of XDATA in use.

rtl837x_port.c

@@ -115,6 +115,9 @@ uint16_t port_pvid_get(uint8_t port) __banked
 
 void vlan_delete(uint16_t vlan) __banked
 {
+	if (!vlan || vlan >= 0xfff)
+		return;
+
 	print_string("\nvlan_delete called \n"); print_short(vlan);
 	vlan_name_remove(vlan);
 	REG_WRITE(RTL837x_TBL_DATA_IN_A, 0, 0, 0, 0);
@@ -197,6 +200,11 @@ __xdata uint16_t vlan_name(register uint16_t vlan) __banked
  */
 void vlan_create(void) __banked
 {
+	if (!vlan_settings.vlan || vlan_settings.vlan >= 0xfff) {
+		print_string("\nInvalid VLAN: "); print_short(vlan_settings.vlan); write_char('\n');
+		return;
+	}
+
 	// For now, the CPU-port is always a tagged member:
 	vlan_settings.members |= 0x0200; // Set 10th bit
 	vlan_settings.tagged |= 0x0200;