feat: add type-safe get_array and get_group methods to AsyncGroup and Group

[d-v-b]

🤖 AI text below 🤖

Summary

Adds type-safe accessors for group members: AsyncGroup.get_array / AsyncGroup.get_group and their sync mirrors Group.get_array / Group.get_group. Each returns the child node at the given path or raises — ArrayNotFoundError / GroupNotFoundError when no node exists, and ContainsGroupError / ContainsArrayError when a node exists but is the wrong kind.

Today group[key] returns the union Array | Group, so callers who know a key refers to an array still need an isinstance check or a cast to get a usefully-typed value. These methods do that narrowing once, with a clear error contract, using the same exception vocabulary as open_array / open_group.

Design notes:

• Path semantics mirror getitem exactly: nested paths like "subgroup/subarray" are supported, on both the plain and consolidated-metadata lookup routes.
• The methods are thin wrappers over getitem, so there is no new I/O logic.
• Several existing tests that fetched a member and then manually narrowed the type (walrus + isinstance asserts in test_zip.py, getitem + isinstance in the consolidated-metadata tests) now use the new methods.

For reviewers

• The main API-design choices worth a second look: the get_array / get_group names (vs. alternatives like an expect parameter on getitem), accepting nested paths rather than restricting to direct children, and the choice of exception types for the two failure modes.
• Confident in: behavior of the wrappers themselves (they delegate to getitem), test coverage (happy path with nested access plus one test per failure mode, across store types and both zarr formats).

Author attestation

• I am a human, these are my changes, and I have reviewed and understood every change and can explain why each is correct.

(Left unchecked: opened by an agent on @d-v-b's behalf; Davis will check this after his own review.)

TODO

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/user-guide/*.md
• Changes documented as a new file in changes/
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

🤖 Generated with Claude Code

[d-v-b]

cc @lhoupert

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.63%. Comparing base (6876120) to head (44e37a1).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4128      +/-   ##
==========================================
+ Coverage   93.62%   93.63%   +0.01%     
==========================================
  Files          90       90              
  Lines       11936    11962      +26     
==========================================
+ Hits        11175    11201      +26     
  Misses        761      761              

Files with missing lines	Coverage Δ
src/zarr/core/group.py	95.33% <100.00%> (+0.13%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[maxrjones]

I think the main design question is actually whether to have this as two functions or one with an expected class argument (analogous to the model https://www.pytables.org/usersguide/libref/file_class.html#tables.File.get_node). Did you already consider that alternative design @d-v-b?

[d-v-b]

I didn't really consider that design because we have a closed set of nodes with just 2 options: array or group. I think if we had a situation where the set of possible node types was dynamic or unbounded (which might be what is going on for pytables?) then get_node might make sense? But even then, I don't think that pytables API is a good idea, compared to giving users tools sufficient to do their own type checking. But since we have just 2 options, and we already have create_array and create_group, get_array and get_group seemed the most ergonomic.