Chore(ci): cap the validation job at 30 minutes

[AmaadMartin]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

N/A

2. Or, if no issue exists, describe the change:

Problem: Every job in this repository inherits GitHub's default 360-minute job timeout. A hung leg of the validation matrix therefore holds a hosted runner for six hours, gives no signal on the pull request, and blocks the queue for other contributors. No workflow sets a timeout today: grep -rn "timeout" .github/ returns nothing on main.

Solution: Set timeout-minutes: 30 on the run-tests job in .github/workflows/validation.yaml. The cap applies per matrix leg; it is not one budget shared across the three legs. I sized it from the last 25 successful validation runs on google/adk-js main (75 legs, completed_at - started_at from the jobs API): the slowest leg was windows-latest at 11.2 minutes, with a windows median of 8.9 minutes and a p95 of 9.6 minutes across all legs. 30 minutes is 2.7x the worst observed leg, so a healthy slow run stays green, and the cost of a hang drops 12x.

Collision check: I scanned all 605 open pull requests on the staging fork. 44 touch validation.yaml, and only #218 adds a timeout to it (timeout-minutes: 60, bundled inside a 528-line test-stabilisation change last updated 29 July). I did not stack on #218, because both changes set the same key on the same job and a stack would produce a duplicate YAML mapping key. #403 adds timeouts to the other five workflows and does not touch this file, so the two changes compose.

Testing Plan

Please describe the tests that you ran to verify your changes. This is required for all PRs that are not small documentation or typo fixes.

Unit Tests:

[ ] I have added or updated unit tests for my change.
[x] All unit tests pass locally.

The diff adds no executable code, so there is nothing to cover and no mutation to record. I did not add a test that reads the workflow and asserts timeout-minutes === 30: it would restate the diff, and it would hard-code a value meant to be tuned. This omission is deliberate.

Manual End-to-End (E2E) Tests:

1. The YAML parses, and the job keys are in the intended order.

   python3 -c "import yaml; print(list(yaml.safe_load(open('.github/workflows/validation.yaml'))['jobs']['run-tests']))"
   -> ['runs-on', 'timeout-minutes', 'strategy', 'steps'], exit 0.

2. Exactly one key was added.

   grep -c "timeout-minutes" .github/workflows/validation.yaml -> 1

3. The change is one line in one file.

   git diff --stat main -> .github/workflows/validation.yaml | 1 +, 1 file changed, 1 insertion(+)

4. The workflow still schedules and passes. GitHub refuses to schedule a malformed workflow, so three green run-tests legs on this pull request are the end-to-end proof. All three passed, each well inside the new cap: ubuntu-latest 5m43s, macos-latest 5m50s, windows-latest 8m44s.

   The first macos-latest attempt failed on a known flake unrelated to this change: tests/integration/app_loader/app_loader_test.ts > "should discover apps vs agents across directories and standalone files" took 43210ms against its 40000ms budget, and that cancelled windows-latest through fail-fast. A one-line workflow key cannot change a test's duration. Both legs passed on re-run.

Checklist

[x] I have read the CONTRIBUTING.md document.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[ ] I have added tests that prove my fix is effective or that my feature works.
[x] New and existing unit tests pass locally with my changes.