Cargo workspace member globs ignore [...] character classes, so members = ["crates/[ab]*"] expands to no members #1833

[agent] Filed by the scheduled architecture audit (audit-core). Register: register.

Kind: bug (with a duplication root cause). Register ID: A02.

Problem

utils/cargo_workspace.rs expands [workspace] members globs with its own matcher. wildcard_match (L425-L436) supports only * and ?, and treats [ as a literal character. Cargo expands members with the glob crate, which supports [abc], [a-z] and [!x] classes.

The crate already has a segment matcher that handles classes: workspace_globs::segment_glob_matches (L680-L692),```` used for the npm-family and pnpm workspaces. A third matcher, fnmatch in `utils/hatch_workspace.rs`, implements Python's fnmatch.

Proof (executed on main @ b291caa). I added a scratch test in a throwaway worktree. The root Cargo.toml has members = ["crates/[ab]*"], and crates/{alpha,beta,gamma} each hold a Cargo.toml. The result:

AUDIT members=[]

Cargo resolves alpha and beta. Every caller of member_manifests / member_manifests_in therefore misses those members:

• vendor/cargo.rs#L199
• patch/redirect/upstream/cargo.rs#L228
• hosted/engine.rs#L731
• hosted/memory/mod.rs#L282

Proposed change

• Delete wildcard_match and its test wildcard_matching.
• In expand_from (L419), call workspace_globs::segment_glob_matches on char slices instead.
• Before switching, check that char_class accepts cargo's [!x] negation spelling. Add ! if it accepts only ^.
• Placement follow-up for the refactor sweep, not needed for this fix: the generic glob walk (DirTree, DiskTree, MemoryTree, expand_glob_bounded, join_rel) belongs in utils/workspace_globs.rs, not in the cargo module. pnpm_workspace.rs already imports it from here.

Size: 1 file, about +3/−20.

Acceptance criteria

• A unit test with members = ["crates/[ab]*"] asserts the alpha and beta manifests are found and gamma is not.
• The existing cargo_workspace tests pass, including the memo-equivalence test.