Fix wslc create network filaure without driver specified

[chemwolf6922]

Summary of the Pull Request

The WSLCSession::CreateNetwork expects Options->Driver to be populated. However, when the driver is not specified in the cli. It's skipped and default to NULL. This PR populates it with the default "bridge" driver when not specified.

PR Checklist

• Closes: Link to issue #xxx
• Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
• Tests: Added/updated if needed and all pass
• Localization: All end user facing strings can be localized
• Dev docs: Added/updated if needed
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

Enable test:
WSLCE2ETests::WSLCE2ENetworkCreateTests::WSLCE2E_Network_Create_DefaultDriver_Success

[Copilot]

Pull request overview

This PR fixes wslc network create failing when --driver is not provided by ensuring the CLI task always supplies a default network driver (bridge) to the underlying WSLC session API. This aligns runtime behavior with the CLI help text and enables the previously-disabled E2E coverage for the default-driver path.

Changes:

• Default CreateNetworkOptions.Driver to "bridge" when --driver is omitted in network create.
• Re-enable the E2E test that validates creating a network without specifying a driver.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
test/windows/wslc/e2e/WSLCE2ENetworkCreateTests.cpp	Re-enables the default-driver network create E2E test and asserts the created network uses bridge.
src/windows/wslc/tasks/NetworkTasks.cpp	Ensures options.Driver is always populated (defaults to "bridge" when not specified).

[dkbennett]

I don't think it is correct for the CLI to be setting a default if the service sets one. The service should handle that and the CLI should not be setting its own default.

[dkbennett]

To add some additional context:

• If the driver needs to be specified, then it should be a required argument
• If the driver is only required in combination with another argument in the command, then we have ValidateArgumentsInternal() for that where such custom validation can be checked and an appropriate error issued.
• If no driver specified is valid and the service sets a default, then the CLI should do nothing and let the service validate it.
• If the driver specification is an Enum or has a limited set of valid options, then the CLI can validate that argument with a validator against the Enum map or similar (see how the Signal argument is processed for a complex example).

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

[chemwolf6922]

@OneBlue Do we want to allow "" being treated as default?

[OneBlue]

@OneBlue Do we want to allow "" being treated as default?

No I think we should consider null being the default, or "" should be rejected