ci: replace addlicense with HawkEye for license header checks

[Standing-Man]

Which issue does this PR close?

• Closes part of Improve pre-push hook granularity and CI maintenance checks #3258.

Rationale

Because license header validation runs on every git commit, the current setup requires starting a Docker container each time. In addition, addlicense only provides an AMD64 Docker image, which can introduce unnecessary overhead on other architectures.

This PR replaces addlicense with HawkEye for license header validation, eliminating the Docker dependency and providing a more lightweight and consistent checking experience.

What changed?

This PR migrates license-header validation to HawkEye and standardizes ASF license headers using a centralized licenserc.toml.

Changes

• Added HawkEye configuration in licenserc.toml, including explicit comment-style mappings and repository-specific excludes.
• Replaced the old license-header check with scripts/ci/license-headers.sh for both local and CI usage.
• Updated CI to install HawkEye through the official action and run the shared license-header script.
• Improved the script’s reliability and diagnostics:
  • parses HawkEye JSON output with jq
  • reports files updated by --fix
  • detects duplicate ASF headers caused by comment-style mismatches
  • prints clearer guidance to keep a single header with the configured comment style
  • fails clearly on unknown file types
• Normalized existing ASF headers across the repository to match the configured styles, including PHP, C/C++, Rust, web, shell, config, SDK, examples, and tests.
• Kept PHP headers aligned with the generated foreign/php/iggy-php.stubs.php style.
• Standardized shell scripts so shebangs are followed directly by the ASF header.

Validation

./scripts/ci/license-headers.sh --check
./scripts/ci/license-headers.sh --fix

Local Execution

• Passed / not passed
  Passed
• Pre-commit hooks ran / not ran
  Ran

AI Usage

1. Which tools? (e.g., GitHub Copilot, Claude, ChatGPT) CodeX
2. Scope of usage? (e.g., autocomplete, generated functions, entire implementation) entire implementation
3. How did you verify the generated code works correctly? I verified it locally by running the relevant tests and manually checking the generated output.
4. Can you explain every line of the code if asked? Yes

[github-actions]

Thanks for the pull request. It is now waiting for review, labeled S-waiting-on-review.

You can update that label as the review goes back and forth, with slash commands - each on its own line, in a regular PR comment (not an inline review reply):

• /ready - mark it S-waiting-on-review again, after addressing feedback
• /author - mark it S-waiting-on-author (maintainers, or anyone who has had a PR merged before)
• /request-review @user ... - request reviewers (@user or @org/team)

Commands take up to ~90s to apply. If no reaction (👍 or 😕) appears on your comment, the apply step likely failed - check the repo's Actions tab for the PR Triage Apply run. Commands posted inside a review body (rather than a normal comment) cannot be reacted to, so they stay log-only.

See CONTRIBUTING.md for details.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.26%. Comparing base (da75706) to head (4825bbb).

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3325      +/-   ##
============================================
- Coverage     74.44%   72.26%   -2.19%     
  Complexity      943      943              
============================================
  Files          1245     1245              
  Lines        121477   116548    -4929     
  Branches      97599    92882    -4717     
============================================
- Hits          90439    84227    -6212     
- Misses        28080    29150    +1070     
- Partials       2958     3171     +213     

Components	Coverage Δ
Rust Core	72.90% <ø> (-2.65%)	⬇️
Java SDK	58.44% <ø> (ø)
C# SDK	69.43% <ø> (-0.50%)	⬇️
Python SDK	81.06% <ø> (ø)
PHP SDK	83.57% <ø> (ø)
Node SDK	91.35% <ø> (-0.06%)	⬇️
Go SDK	40.20% <ø> (ø)

Files with missing lines	Coverage Δ
core/ai/mcp/src/api.rs	36.84% <ø> (ø)
core/ai/mcp/src/configs.rs	44.24% <ø> (ø)
core/ai/mcp/src/log.rs	13.33% <ø> (ø)
core/ai/mcp/src/main.rs	54.54% <ø> (+1.01%)	⬆️
core/ai/mcp/src/service/mod.rs	60.28% <ø> (ø)
core/ai/mcp/src/service/requests.rs	100.00% <ø> (ø)
core/ai/mcp/src/stream.rs	75.91% <ø> (+0.72%)	⬆️
core/cli/src/args/common.rs	97.87% <ø> (ø)
core/cli/src/args/context.rs	100.00% <ø> (ø)
core/cli/src/args/message.rs	66.12% <ø> (ø)
... and 102 more

... and 625 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Standing-Man]

Unrelated fixes included in this PR:

1. Fixed the helmfmt pre-commit hook, which was not passing any arguments and could cause the check to fail.
2. Fixed an indentation issue in foreign/csharp/Benchmarks/Program.cs.
3. Updated cli::system::test_login_command::should_help_match to replace hidden whitespace used for indentation with an explicit CLAP_INDENT constant, since the original blank-space formatting could be removed by the trailing-whitespace check.

The current license header validation is overly strict. In some cases, a file already contains a valid license header using one comment style, but the checker still reports the file as missing a license header. As a result, running --fix may insert another license header using a different comment style, leading to duplicate license headers in the same file.

To prevent this issue, duplicate license header check has been added to the license header validation script. cc @hubcio

/ready

[hubcio]

@Standing-Man i was thinking about this:

The current license header validation is overly strict. In some cases, a file already contains a valid license header using one comment style, but the checker still reports the file as missing a license header. As a result, running --fix may insert another license header using a different comment style, leading to duplicate license headers in the same file.

perhaps this is good issue to raise in hawkeye repository?

[hubcio]

the local pre-commit path now needs hawkeye (compiled from source via cargo install, slow the first time) and jq installed on the host. neither is mentioned in CONTRIBUTING, so a line there would save contributors a confusing first run. or perhaps can you create a Tooling section in CONTRIBUTING.md, where you'll list all tools needed for percommit hooks to pass?

[hubcio]

a few items from re-reviewing the latest push.

on CONTRIBUTING.md (not in the diff, so noting it here): the pre-commit license-headers hook is language: system and runs license-headers.sh, which hard-fails with "hawkeye command not found" if hawkeye isn't on PATH. so every contributor now needs cargo install hawkeye --version 6.5.1 --locked locally, but the pre-commit hooks section only documents prek and typos-cli. the first commit after prek install will fail until they read the script's hint. worth adding hawkeye to the install list.

after you fix these comments below (+ this one above) i believe we can merge.

[Standing-Man]

/ready

[Standing-Man]

@Standing-Man i was thinking about this:

The current license header validation is overly strict. In some cases, a file already contains a valid license header using one comment style, but the checker still reports the file as missing a license header. As a result, running --fix may insert another license header using a different comment style, leading to duplicate license headers in the same file.

perhaps this is good issue to raise in hawkeye repository?

Good suggestion, I’ll check the HawkEye repository and verify whether this can be raised as an enhancement issue.

If we don’t enforce a strict one-to-one mapping between file types and comment styles, the license header check would also avoid this kind of issue.

[Standing-Man]

Thank you very much for your review. This has been quite a journey. 😂 @hubcio

[hubcio]

yeah, i think its one of biggest PRs. good that you've found hawkeye, i wasn't fully happy with addlicense. good job!