Fix Zarr fill-value masking options for DataTree reads

[anshurajbisoyi98-ctrl]

Description

Fixes an issue where use_zarr_fill_value_as_mask was not accepted when reading Zarr data through the DataTree and group-opening APIs.

The option already controls fill-value masking in the Zarr store, so I forwarded it through open_datatree() → open_groups_as_dict() → ZarrStore.open_store(). This lets DataTree reads reuse the existing masking behaviour without adding a second implementation. The chosen setting now applies consistently to the root and child groups, and the format-dependent defaults are unchanged when no setting is passed or it is set to None.

Cause: The Zarr DataTree and group-opening methods did not accept or forward use_zarr_fill_value_as_mask.

Tests: I added 12 regression cases covering both opening APIs, Zarr formats 2 and 3, True/False/None, and root and child groups. All 12 failed before the fix and passed afterward.

Additional change: A separate commit fixes existing NamedArray masked-array typing errors and adds three unmasked-array test cases.

Docs: Updated the I/O guide and the release notes.

Validation:

• Zarr/DataTree suites: 1,751 passed, 146 skipped, 20 expected failures.
• After the typing fix, NamedArray and Zarr DataTree tests: 105 passed, 1 skipped, 3 expected failures.
• Mypy passed for 203 files, and the standard hooks passed.

Not verified: full-project tests, other platforms, and remote CI.

Checklist

• Closes add use_zarr_fill_value_as_mask in open_datatree for Zarr Stores #11361
• Tests added
• User-visible changes (including notable bug fixes) are documented in whats-new.rst

AI Disclosure

• This PR contains AI-generated content.

  • I have tested any AI-generated content in my PR.

  • I take responsibility for any AI-generated content in my PR.

    Tools: Codex (used for investigation, implementation, tests, verification, documentation, and wording edits to this description).

    Prompt summary: Address add use_zarr_fill_value_as_mask in open_datatree for Zarr Stores #11361 using established repository patterns, add regression tests, verify the changes locally, and fix the remaining masked-array typing errors before submission.

[anshurajbisoyi98-ctrl]

The two failing checks appear to report the same six PyDAP network-test timeouts: test-py314 (flaky) and its aggregated Test Results check. These tests access test.opendap.org, which was also unreachable during investigation. The other 13 test jobs passed, and all 12 Zarr masking regression cases pass locally.
Could a maintainer rerun the failed job to check whether this was a transient network issue?

[anshurajbisoyi98-ctrl]

The two remaining failures are test_batchdap4_downloads[dap2] and test_batchdap4_downloads[dap4] in the flaky/network test job. Both fail while reaching test.opendap.org (HTTP 503 / connection refused); I also confirmed the endpoint is currently returning 503. The other platform test jobs, typing checks, docs, and pre-commit checks passed. These failures appear to be caused by the external OPeNDAP service outage, rather than this PR. Could you please advise whether you would prefer a rerun once the service is available?

[headtr1ck]

Thanks!

[headtr1ck]

I took the liberty to fix up the failed what's -new merge.
Looking good!

[anshurajbisoyi98-ctrl]

Thanks a lot for fixing the whats-new merge, and sorry, I hadn't noticed that it dropped the #11736 and #11722 entries. Combining the entry with #11748 makes sense.