ci: run tests and linters on pull requests to any base branch

[mlwelles]

Description

ci-dgraph4j-tests.yml and trunk.yml both filtered their pull_request trigger to base branch main, excluding any pull request aimed at a feature branch. Only CodeQL ran on one, since it comes from GitHub's default setup rather than a workflow in this repo.

That combination is worse than having no checks at all. GitHub reports such a pull request mergeable: MERGEABLE and mergeStateStatus: CLEAN, because checks that are absent cannot fail — so it reads as validated while nothing has validated it. Measured on #297 ("fix: report a missing refresh token as AuthException"), which is based on a feature branch: 4 checks present against 7 on a pull request based on main, with dgraph4j-tests, Trunk Check, and Trunk Code Quality / Check all missing.

Why native stacked PRs do not make this redundant

Native stacks cover part of the gap on their own: #297 now runs dgraph4j-tests despite its base being fix/async-client-non-blocking-retries. The linters still do not run there — no Trunk Check, no Trunk Code Quality / Check — so a stacked pull request is tested but unlinted. This PR closes that half.

It also stops coverage depending on inferred behavior. Nothing documents why the suite now runs on a non-main base while the linters do not, and an explicit trigger outlasts that asymmetry. gh stack merge lands a whole stack atomically, so every entry wants its full checks before that happens, not after.

Two commits, reviewable separately

1. ci: run tests and linters on pull requests to any base branch — drops the branches filter from pull_request in both workflows. Dropping it beats listing prefixes such as fix/**: a pull request deserves the same checks wherever it is aimed, and an allowlist needs editing for every new naming convention. push stays limited to main, so no feature-branch push triggers a build on its own, and the nightly schedule is untouched.

2. ci: cancel superseded pull request runs — the cost offset, and droppable on its own if you would rather not take it. Widening the trigger means the Dgraph-from-source build runs on stacked pull requests too, and a chain of N runs it N times. This cancels the in-flight run when a pull request is pushed again. cancel-in-progress is gated on the event being a pull_request, so a main push or the nightly schedule is never cancelled.

Verification

• Both files parse, and the trigger structure is confirmed: push still {branches: [main]}, pull_request keeps its four activity types with no branch filter, schedule unchanged.
• trunk check .github/workflows/ reports no issues, actionlint included.
• This PR targets main, so it cannot demonstrate the fix on itself. The check count on fix: report a missing refresh token as AuthException #297 rising from 4 to 7 after this merges is the observable outcome.

No source or public API changes. Per this repo's precedent for CI-only changes — chore (ci): add stale action (#291) has no entry — there is no CHANGELOG.md addition.

Checklist

• Code compiles correctly and linting passes locally
• For all code changes, an entry added to the CHANGELOG.md file describing and linking to
  this PR — n/a, CI configuration only, matching the precedent above
• Tests added for new functionality, or regression tests for bug fixes added as applicable —
  n/a, no behavior to test; the effect is observable as check coverage on stacked pull requests

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}