build: merge code formatter CI workflow with the validation build, test only after formatter succeeds

[Artur-]

Merges the separate formatter workflow into the validation workflow with
automatic commit and push capabilities for formatting changes.

Changes:

• Deleted standalone .github/workflows/formatter.yml
• Integrated formatter as first job in validation.yml workflow
• Added auto-commit functionality using PAT token (VAADIN_BOT_TOKEN)
• Formatter now commits and pushes changes when formatting issues detected
• Workflow stops after committing, new workflow run is triggered by the commit
• On second run, detects bot commit and skips formatting, proceeds to validation
• Changed workflow permissions to include contents:write for pushing commits
• Build and test jobs only run if formatter succeeds (no changes or after bot commit)

Infinite loop prevention:

• Checks if last commit author is github-actions[bot]
• If true, skips formatting step and proceeds to validation
• Prevents endless formatting cycles if formatter is inconsistent

Token requirements:

• Requires VAADIN_BOT_TOKEN secret with repo and workflow permissions
• Workflow fails immediately if token is not configured
• PAT needed because GITHUB_TOKEN cannot trigger workflow runs

PR comment behavior:

• Posts comment when formatting changes are auto-committed
• Deletes comment when formatting is correct
• Includes list of files that were modified

[github-actions]

Test Results

1 270 files  +  4  1 270 suites  +4   1h 14m 46s ⏱️ + 1m 26s
8 768 tests +117  8 701 ✅ +116  67 💤 +2  0 ❌  - 1 
9 221 runs  +145  9 144 ✅ +145  77 💤 +1  0 ❌  - 1 

Results for commit 26592ca. ± Comparison against base commit 6aadc0c.

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
2489 New issues
2 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[platosha]

Just a question: do I understand correctly, that this change makes validation workflow unusable for external contributor PRs, since the bot cannot push to respective branches? If so, would it make sense to introduce a fallback to just checking formatting in the absence of push access?

[Artur-]

Most often contributors tend to check the checkbox that maintainers can make updates. Does this mean that formatting will also work? I have not tried

[platosha]

I think, this condition needs to removed or adjusted. I tried dispatching this workflow from the PR branch manually using the dispatch button, here's what happened:

• it skipped the formatter job because it was not the pull_request_target event,
• then it skipped the build job probably because formatter is required,
• then it skipped the testing jobs also,
• ...and then it reported a false positive, oh no!

See: https://github.com/vaadin/flow/actions/runs/18466985120

Keeping the manual dispatch function working is useful for enabling maintainers to verify workflow changes from PR branches. Let's not limit the supported triggers. If auto-commit from the formatter isn't appropriate, it could fallback to checking only.