refactor(ci): auto-run workflow

[Ma77Ball]

What changes were proposed in this PR?

The build workflow now runs automatically for all PRs. All three build jobs (frontend, scala, python) trigger directly on push, pull_request, and workflow_dispatch events, making CI faster and easier to reason about for all contributors.

Any related issues, documentation, discussions?

Closes: #4290

How was this PR tested?

Verified that all three build jobs (frontend, scala, python) trigger automatically on pull request open, push, and synchronize events.

Was this PR authored or co-authored using generative AI tooling?

Resolved comments with Claude Sonnet 4.6

[Ma77Ball]

@Yicong-Huang to address this comment (#4278 (comment)):

The core issue is that the workflow currently has no pull_request trigger at all, which is why it doesn't run for anyone — committers or not. The fix simply adds the pull_request trigger with the standard event types (opened, synchronize, reopened), which is what makes GitHub automatically run the workflow for all PRs, including forks.

The reason this works for fork contributors without explicit approval is that adding pull_request (not pull_request_target) to the trigger is GitHub's built-in mechanism for running CI on PRs. GitHub handles fork isolation automatically by running the workflow with read-only tokens and no access to secrets. No committer approval step is needed because GitHub's own sandboxing is what keeps fork PRs safe.

[Yicong-Huang]

@Yicong-Huang to address this comment (#4278 (comment)):

The core issue is that the workflow currently has no pull_request trigger at all, which is why it doesn't run for anyone — committers or not. The fix simply adds the pull_request trigger with the standard event types (opened, synchronize, reopened), which is what makes GitHub automatically run the workflow for all PRs, including forks.

Sorry I am more confused. We had pull_request: so it will trigger for ALL types of events from pull_request. And the CIs were automatically triggered for committers.

But the new change limits it to [open, sychronize, reopened] which are typically more restricted.

I couldn't understand why it can resolve the issue?