fix(dependency_groups): collect InvalidRequirement instead of leaking it

[r266-tech]

Follow-up to #1248. In DependencyGroupResolver._parse_group, the string-item branch builds Requirement(item) and lets InvalidRequirement propagate raw — the only branch in that loop that doesn't route through the error collector.

A single malformed PEP 508 requirement string therefore:

1. drops sibling errors already collected for that group — the raw raise short-circuits the loop, so the post-loop if errors.errors: return () is never reached and any error collected earlier in the same loop (an invalid object {}, a non-string include-group, an unknown item type) is lost; and
2. escapes the documented aggregated [dependency-groups] data for <group> was malformed ExceptionGroup as a bare InvalidRequirement.

#1248 collected the adjacent include-group TypeError in the same loop but left this branch raw. The fix wraps the parse in errors.collect(InvalidRequirement) — the collector's own documented in-loop helper (InvalidRequirement subclasses ValueError, so it's collectible) — so all malformed-group diagnostics are uniform and complete.

lookup() / resolve() document the aggregated-ExceptionGroup contract (not :raises InvalidRequirement), so this aligns the string branch with the port's actual contract rather than changing it. The regression test asserts a bad requirement string is now reported together with a co-occurring sibling error instead of dropping it.