Network Namespace extension should support untagged public networks

## Summary

The current Network Namespace extension code does not support an untagged public network. It treats the public VLAN value as a numeric VLAN ID and attempts to create a VLAN sub-interface. In an environment where the public network is intentionally untagged, this causes the following Marvin tests to fail if the Public network is not tagged (a valid scenario):

- `test_05_isolated_network_full_lifecycle`
- `test_06_vpc_multi_tier_and_restart`
- `test_07_vpc_network_acl`
- `test_09_vpc_source_nat_ip_update`

The later Static NAT and port-forwarding errors appear to be consequences of the initial public-network setup failure, rather than four unrelated test failures.

## Environment

- CloudStack Marvin smoke tests
- Network Namespace extension
- Public network is untagged and uses the existing bridge/uplink path
- No tagged public VLAN is available on this test network

## Observed behavior

The extension attempts to create a VLAN interface using the literal value `untagged`, resulting in an error similar to:

`Error: argument "untagged" is wrong: id is invalid`

The Network Namespace extension script then exits with code 2, and the dependent network operations fail.

## Expected behavior

When the configured public network is untagged, the extension should:

1. Skip creation of an `ethX.` VLAN sub-interface.
2. Use the existing bridge or physical uplink directly.
3. Continue with the required address, route, ARP, and NAT setup.
4. Preserve the current behavior for numeric VLAN configurations.

A public network does not inherently require VLAN tagging; both tagged and untagged deployments are valid. Supporting the explicit `untagged` mode would allow the same tests to run on simple bridge/NAT-based lab networks without requiring an artificial VLAN configuration.

## Validation

Please consider adding coverage for both:

- Numeric VLAN configuration, preserving current tagged behavior.
- Explicit untagged configuration, without creating a VLAN sub-interface.

It would also be helpful if the extension scripts used by a test run could be pinned to a commit or release, rather than fetched from a moving branch at runtime, so that failures remain reproducible.

This issue concerns the Network Namespace extension only; it is not a change to the default CloudStack Virtual Router path.

Start with the Network Namespace extension script and the public-network setup path, then run the listed Marvin tests: test_05_isolated_network_full_lifecycle, test_06_vpc_multi_tier_and_restart, test_07_vpc_network_acl, and test_09_vpc_source_nat_ip_update. Verify that numeric VLAN configurations retain their current behavior and that explicit untagged configuration completes address, route, ARP, and NAT setup without creating a VLAN sub-interface.

Written by the indexing model from the issue text.