[Maintenance] Proposal: Triage strategy for increasing volume of low-value/spam issues

The issue tracker is currently accumulating a significant amount of noise. Several issues are being opened that contain only raw code dumps with no bug description, feature request, or contextual question. These issues clutter the backlog and distract from legitimate repository maintenance.

This is an ongoing problem that was originally raised back in 2019 (see #389) and remains unresolved. Furthermore, other community members such as @space-contributes have recently pointed out this exact problem (e.g., in #864), validating that this lack of context is a shared frustration for contributors trying to navigate the tracker.

Examples of recent non-contributing issues:

• #864 (Raw code dump, no description)
• #862 (Raw code dump, no description)
• #856 (Raw code dump, no description)

Examples of spamming issues by the same user:

• #858 (Raw code dump, no description)
• #859 (Raw code dump, no description)
• #860 (Raw code dump, no description)
• #861 (Raw code dump, no description)

To manage this, I propose implementing the following steps to clean up the tracker and prevent future spam:

1. Backlog Triage: Conduct a sweep to identify and close all currently open issues that are unrelated to the main library focus or lack actionable context.
2. Standardized Tagging: Create a specific label (e.g., spam, invalid, or noise) to easily mark these issues for human review and bulk closing.
3. Automated Triage Agent: Implement an automated workflow (via GitHub Actions) to identify and tag or automatically close potentially unnecessary issues based on heuristics (e.g., issue bodies containing fewer than 20 words of regular text outside of code blocks).
4. Enforce Issue Forms: Switch from legacy markdown templates to YAML-based GitHub Issue Forms, making fields like "Description" and "Steps to Reproduce" strictly mandatory to block empty submissions at the UI level.
5. Update Contributing Guidelines: Explicitly state in CONTRIBUTING.md that unsolicited code dumps without a clear problem statement will be closed immediately.
6. Account Moderation: Establish a threshold to block users who repeatedly spam the repository after warnings.

Implementing these steps will significantly reduce the moderation burden and keep the focus on actual bug fixes and feature development.

Suggested Changes for CONTRIBUTING.md

The current guidelines focus entirely on Pull Requests. Additionally, I suggest adding a new section specifically addressing Issue creation to set strict boundaries on what is acceptable, placed right before the "How to contribute" or "Want to pitch in?" sections.

Here is the suggested snippet to add:

### Opening Issues

We rely on the issue tracker to manage bugs and feature requests. To help us keep the project organized, please follow these guidelines when opening an issue:

1. **Search first:** Check the existing issues to ensure your bug or feature request hasn't already been reported.
2. **Provide context:** You must include a clear description of **what** the issue is and **why** it matters. 
3. **Bug reports:** Include steps to reproduce, the expected behavior, and the actual behavior.
4. **Feature requests:** Explain the use case and how it benefits the library.

**Important:** Issues that consist solely of raw code dumps, random scripts, or lack a basic description of a problem/proposal do not add value to the project. These will be labeled as invalid and closed immediately without review.