feat(resource): restrict resource records in lists

[johanpel]

Description

Reject resource usage and bounds records inside list types. This is ambiguous, because which instance of the bounds is the truth?

Options are allowed, because I don't want to restrict users from emitting this conditionally to prevent an explosion of event declarations.

If the user desires to do something with bounds (e.g. visualize, check for leaks, etc.) then in the case of optional bounds events it is their responsibility to make sure they are conveyed. This is already the case because we can't force client code to emit certain events, so if a resource has multiple events of which only one sets bounds, but doesn't emit that event, you're basically in the same boat.

Related Issues

Surfaced while working on #427

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: QUIET

Plan: Enterprise

Run ID: 89106fcf-8bdb-4ccc-99ae-c0bc723fbba4

📥 Commits

Reviewing files that changed from the base of the PR and between 117fc41 and 2bdcde0.

📒 Files selected for processing (2)

• crates/resource/src/lib.rs
• crates/resource/tests/resource-constraint.rs

---

📝 Walkthrough

Walkthrough

The resource constraint now tracks list placement for usage and bounds records, rejects invalid placements with dedicated ResourceError variants, and adds tests for optional and listed record payloads.

Changes

Resource record validation

Layer / File(s)	Summary
Track record placement crates/resource/src/lib.rs	Record references capture list context during traversal, while the requirements and public error enum describe usage and bounds list-placement violations.
Validate and test list placement crates/resource/src/lib.rs, crates/resource/tests/resource-constraint.rs	Usage and bounds validation reports UsageInList and BoundsInList; test helpers support arbitrary payload types and tests cover optional acceptance and list rejection.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related PRs

• rapidsai/quent#387: Introduces the resource constraint and validation structures extended here with list-specific record checks.

Suggested reviewers: mbrobbel, dhruv9vats

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	It clearly summarizes the main change: restricting resource records in lists.
Description check	✅ Passed	It covers the purpose and related issue; only the optional Testing and Screenshots sections are omitted.
Docstring Coverage	✅ Passed	Docstring coverage is 90.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[mbrobbel]

I understand this for bounds, but why do you also want to restrict usage in a list?

[johanpel]

I understand this for bounds, but why do you also want to restrict usage in a list?

Good point, we should certainly allow a list of references with usages to multiple instances of the same type of resource entity: 2bdcde0

[johanpel]

/merge