xtask test-csharp: source mapping verification fails when nuget.org is unreachable

Problem

The source mapping verification in cargo xtask test-csharp (in xtask/src/tasks/bindings/csharp.rs) expects dotnet restore to fail with NU1101 (package not found) to confirm that Microsoft.Regorus cannot be resolved from external sources via package source mapping.

However, in environments where api.nuget.org is unreachable (e.g., air-gapped CI, restricted networks, corporate proxies), the restore fails with NU1301 (unable to load service index) instead. The verification then treats this as an unexpected failure and aborts.

Expected Behavior

The verification should handle the case where the external source is unreachable. Possible approaches:

1. Accept NU1301 as evidence that external resolution is blocked (though this is weaker — it proves unreachability, not that source mapping works).
2. Add a CLI flag or environment variable (e.g., --skip-source-mapping-verify or REGORUS_SKIP_SOURCE_MAPPING_VERIFY) to allow skipping the verification in environments where it cannot succeed.
3. Allow the nuget.org URL in bindings/csharp/nuget.config to be overridden (e.g., via an environment variable or additional CLI option) so users can point it at a reachable mirror.

Reproduction

Run cargo xtask test-csharp --release --nuget-dir <dir> in an environment where https://api.nuget.org/v3/index.json is not accessible.

Relevant Code

xtask/src/tasks/bindings/csharp.rs, lines 506–514:

// Ensure the failure is specifically NU1101 for Microsoft.Regorus, not an
// unrelated error (e.g. network outage).
        "Source mapping verification failed: dotnet restore failed, but not for the \
         expected reason. Expected NU1101 for Microsoft.Regorus to confirm external \
         resolution is blocked.\nstdout:\n{stdout}\nstderr:\n{stderr}"
    ));
}

Start in xtask/src/tasks/bindings/csharp.rs around lines 506–514 and reproduce with cargo xtask test-csharp --release --nuget-dir

while api.nuget.org is unreachable. Read bindings/csharp/nuget.config and the existing NU1101 validation to understand the available handling options. Done means the verification behaves as documented in restricted-network environments without masking unrelated restore failures.