### Description
<!-- Please provide a clear and concise description of what this PR does and why it is needed, in your own words. -->

**AI use:** Yes / No
<!-- Select Yes if AI helped generate or modify submitted code or tests, draft substantive PR text, or create the PR. Tool names and prompts are not required. -->

### Related Issues
<!-- List related issues, such as "Fixes #123" or "Related to #456". When prior agreement is required, link the maintainer's agreement on the intended behavior and scope. Otherwise, explain the small-change exception. For a larger change, link the agreed design and identify this phase. -->

### Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Documentation update
- [ ] Refactor
- [ ] Other (please describe):

### Checklist
Please review and check all that apply. Leave unverified items unchecked and explain them under How to Test.

- [ ] My code follows the project’s coding style
- [ ] I have tested the changes locally
- [ ] I have added or updated documentation as needed
- [ ] I have added tests that prove my fix/feature works (or explain why not)
- [ ] All existing and new tests pass
- [ ] I personally read and reviewed the entire diff and relevant code before opening this PR, and have done the same for every subsequent update, if any.
- [ ] For code changes, I have the development knowledge to understand, test, and maintain the implementation, assess its security and performance implications, and answer review questions.

### How to Test
<!-- Describe the steps to test your changes. Include setup, commands actually run, and results actually observed before and after the change. State how you personally checked the affected functionality. List failed or unrun checks, untested cases, and limitations. -->

### Screenshots / Demos (if applicable)
<!-- Add screenshots, GIFs, or links to demos if your change includes UI updates or visual changes. -->

### Additional Notes
<!-- Anything else the maintainer should know? Potential side effects, breaking changes, or areas of concern? Where relevant, explain important tradeoffs, new dependencies or ongoing maintenance costs, and simpler alternatives considered. -->

<!-- 
**Tips for Contributors:**
- Be concise but thorough.
- If your PR is large, consider breaking it into smaller PRs within the agreed design and scope.
- Review timing depends on maintainer availability; please do not tag the maintainer for faster review.
- Avoid force pushing to the branch after opening the PR, as it can complicate the review process.
-->