ci: Enhance boards test validation

[P-R-O-C-H-Y]

Description of Change

This pull request improves the board validation process in the CI workflows by introducing a reusable validation script and enhancing the accuracy of board detection. The main changes focus on centralizing board validation logic, ensuring only actual boards are processed, and updating workflow steps to use the new script. PR includes also fixes for boards that are not passing the Rules 2-6.

Board validation improvements:

• Added .github/scripts/validate_board.sh and updated both boards.yml and allboards.yml workflows to use this script for validating board definitions, replacing inline validation logic. [1] [2]

• 6 Validation Rules for ESP32 Boards:

  • Rule 1: Build Board Format
    build.board must be uppercase letters, numbers, and underscores only
    Example: ESP32_DEV ✅ | esp32-dev ❌
  • Rule 2: Required Properties
    Must have upload.flags and upload.extra_flags defined
  • Rule 3: Partition Scheme Validation
    All partition schemes must fit within board's flash size
    Checks scheme names, descriptions, and upload limits
  • Rule 4: VID/PID Consistency
    No duplicate VID/PID entries
    VID and PID indices must match (vid.0 ↔ pid.0)
    Prevents any board from using the reserved ESP32 family ID (0x303a/0x1001)
  • Rule 5: DebugLevel Menu
    Must have all 6 debug levels: none, error, warn, info, debug, verbose
    Each with correct code_debug values (0-5)
  • Rule 6: No duplicate lines
    Looks for the same property defined twice for one board (catching copy-paste errors)
    Shows exactly where the duplicates are in the file

Board detection enhancements:

• Refactored .github/scripts/find_new_boards.sh to use an excluded_entries array for filtering out non-board entries, making board detection more robust and maintainable.

Workflow updates:

• In allboards.yml, added steps to make the validation script executable and validate each board in the chunk, reporting failures and stopping the workflow if any board fails validation.
• In boards.yml, replaced the previous uppercase check for build.board with the new validation script for consistency and improved reliability.

Board Definition Updates (boards.txt):

• Updated the maximum upload size for the "Custom" partition scheme for multiple boards, reducing it from 16MB to either 4MB or 8MB, depending on the board. [1] [2] [3] [4] [5] [6] [7]
• Removed several 8MB and 16MB partition scheme options (such as default_8MB, fatflash, and app3M_fat9M_16MB) from various boards to streamline the available choices and possibly reflect hardware or support changes. [1] [2] [3] [4] [5] [6] [7]
• Added or corrected partition scheme definitions for some boards, such as introducing missing build.partitions and upload.maximum_size entries for app3M_fat9M_16MB on esp32s3-octal.
• Updated flash size for um_tinyc6 from 4MB to 8MB, reflecting a hardware change.
• Added a new debug level "Verbose" for S_ODI_Ultra.

These changes collectively improve the reliability of board validation in CI and keep the board definitions up-to-date with current hardware and support requirements.

Test Scenarios

Tested locally

Related links

[github-actions]

	Messages
📖	This PR seems to be quite large (total lines of code: 1003), you might consider splitting it into smaller PRs

👋 Hello P-R-O-C-H-Y, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Addressing info messages (📖) is strongly recommended; they're less critical but valuable.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests.

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
4. If the change is approved and passes the tests it is merged into the default branch.

Generated by 🚫 dangerJS against a2eaf1d

[P-R-O-C-H-Y]

@me-no-dev @lucasssvaz PR is ready for your review :)