[Bug]: REST listTasks drops historyLength=0 and accepts NaN pageSize

### What happened?

`RestTransportHandler.listTasks` builds params with truthy coercions:

```
historyLength: queryParams.historyLength ? Number(...) : undefined
pageSize: queryParams.pageSize ? Number(...) : undefined
```

Express query values are strings, so `historyLength=0` and `pageSize=0` become undefined. Spec and `DefaultRequestHandler._applyHistoryLengthSemantics` treat 0 as "omit history". `getTask` already keeps 0 via `parseHistoryLength`. The JS REST client sends `historyLength=0`, so a same-SDK listTasks call returns full history.

Non-numeric `pageSize=abc` becomes NaN. The handler only checks `pageSize < 1 || pageSize > 100`, and both comparisons are false for NaN, so the store does `tasks.slice(0, NaN)` and returns an empty page with HTTP 200.

Related: closed unmerged PR #625 diagnosed the REST Number() hole. Open PR #639 caps historyLength at 1000 but does not fix the truthy drop of 0 or NaN pageSize.

**Repro**
1. Persist a task with at least two history messages.
2. `GET /tasks?historyLength=0` with `A2A-Version: 1.0`.
Observed: full history. Expected: `history` is `[]`.
3. `GET /tasks?pageSize=abc`.
Observed: 200 with `tasks=[]`. Expected: 400 RequestMalformedError.

### Relevant log output

n/a.

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Look at RestTransportHandler.listTasks in the codebase, likely in a file like src/transport/rest.ts. The bug is in the truthy coercion for historyLength and pageSize. Start by understanding how query parameters are parsed and where Number() conversions happen. Check related PRs #625 and #639 for context. Write a test to reproduce the described behavior, then fix the coercion to handle 0 and NaN correctly. Ensure the fix aligns with the spec's handling of historyLength=0 and returns a 400 error for non-numeric pageSize.

索引モデルが issue の本文から書いたものです。