Deprecation Cycle for `netcdf4` backend URL behavior

What is your issue?

As discussed in https://github.com/pydata/xarray/pull/10931 and https://github.com/pydata/xarray/pull/10804 the netcdf4 backend currently claims all URLs via it's guess_can_open method.

https://github.com/pydata/xarray/blob/6e82a3afa8e47e7ed59441e77f812ceeaeaf5668/xarray/backends/netCDF4_.py#L718-L731

This is overeager and led to issues such as https://github.com/pydata/xarray/issues/10801. Therefore this behavior needs to be deprecated in favor of either more explicit options https://github.com/pydata/xarray/pull/10931#issuecomment-3560387850 or at a minimum a tighter scope for what URLs the backend claims in it's guess method.

However, some users and workflows currently rely on this behavior, which caused failures: https://github.com/pydata/xarray/pull/10804#discussion_r2542097630

Therefore, any changes will require a long deprecation cycle with a warning emitted when a user relies on the to-be-changed guessing behavior.

Questions

1. What should the end state be?

Is this a wholesale change of guessing behavior for all backends - potentially removing guessing in favor of always explicit speccificaiton? Or is this a smaller descoping of what URLs the netcdf4 backend claims?

2. What time frame?

I propose the 2026.01.0 release

Additional reading

The URL-pipeline syntax originally proposed in ZEP8, that now lives here: https://github.com/jbms/url-pipeline#url-pipeline-specification seems as though it would be able to solve the issues here (e.g. specifying if something is a dap url)

Start with xarray/backends/netCDF4_.py around lines 718-731 and review the linked pull requests and issue discussions about guess_can_open. Determine whether the project wants a broader guessing change or a narrower netcdf4 scope, then define the deprecation warning and target release. Done means the end state and deprecation cycle are agreed and documented.