[CI] ci.yml build matrix fail-fast cancels sibling OS jobs; build job has no timeout-minutes

### [CI] `ci.yml` build matrix cancels sibling OS jobs on first failure and the `build` job has no `timeout-minutes`

While diagnosing a `build` workflow failure (run [30756841941](https://github.com/apache/shenyu/actions/runs/30756841941) on PR #6456), I found two `ci.yml` config issues that make build failures harder to diagnose and waste runner time. Neither is the cause of any specific test failure — they're CI-hygiene improvements surfaced while tracing one.

#### 1. `build` matrix uses the default `fail-fast: true`

`.github/workflows/ci.yml`'s `build` job defines a `strategy.matrix` of 5 jobs (`windows-latest`/Java 17, `ubuntu-latest`/Java 17/19/20/21) but does not set `fail-fast`, so the GitHub default `fail-fast: true` applies: when one matrix job fails, the others are cancelled mid-build.

In run 30756841941, `build (17, windows-latest)` failed with real test errors, and the four ubuntu jobs were each cancelled ~7 minutes into their builds (`status: cancelled`, log error `The operation was canceled.`). Concretely, this:

- **Wastes partial build work.** Each cancelled ubuntu job had already compiled and tested many modules (~7 min) before being killed; that work is thrown away and re-run from scratch on the next push.
- **Obscures whether a failure is OS-specific or universal.** Four of five jobs show "canceled" rather than a real result, so a reviewer has to open the per-job conclusions to find which job actually failed versus was merely cancelled. In this case the ubuntu jobs had not yet reached the failing module, so it was not obvious that the failure was platform-independent.

Suggestion: set `fail-fast: false` on the `build` strategy so each OS job completes, making OS-specific vs universal failures immediately distinguishable and avoiding the cancelled-sibling confusion.

```yaml
build:
needs: changes
strategy:
fail-fast: false
matrix:
...
```

#### 2. The `build` job has no `timeout-minutes`

Only `check-license-header` sets `timeout-minutes` (10). The `build` job runs the full reactor (`mvnd -B clean test -Prelease -DskipRemoteResources=true` on Linux, `./mvnw.cmd -B clean test -Prelease` on Windows) and inherits GitHub's default 6-hour job timeout. A hung build (e.g., a test blocking on a socket) could consume a runner for up to 6 hours before being killed.

Suggestion: set an explicit `timeout-minutes` on the `build` job (e.g., 60–90) so a hung build fails fast instead of holding a runner for hours.

```yaml
- name: Build with Maven
shell: bash
timeout-minutes: 90
run: |
...
```

#### Side note on `concurrency.cancel-in-progress`

The workflow already has `concurrency: { cancel-in-progress: true }` keyed by PR number, which is the right call for saving CI minutes on actively-iterated PRs. The `fail-fast`/`timeout-minutes` items above are independent of that and complementary.

Open .github/workflows/ci.yml and inspect the build job's matrix strategy and Maven build steps, using run 30756841941 as context. Done means sibling matrix jobs continue after one failure and the build has an explicit timeout-minutes value; validate the workflow configuration and confirm the resulting job behavior.

Written by the indexing model from the issue text.