Storage policy chunk_concurrency is parsed as i32: an out-of-range value breaks the entire directory listing

## Summary

The client deserializes the storage policy field `chunk_concurrency` into an `i32`. When the server-side storage policy holds a value larger than `i32::MAX` (2147483647), serde fails on the **entire** JSON response rather than just that field.

Because `storage_policy` is embedded in the file-listing response, this makes the sync root permanently unusable: registration and `CfConnectSyncRoot` both succeed, but no placeholder can ever be created, so Explorer shows "cloud service unavailable" on a folder that is otherwise a perfectly valid sync root. Nothing in the UI hints at the cause — you have to read the log to find it.

## Environment

- Client: 0.2.0.0 (Microsoft Store package `2106abslant.Cloudreve`)
- OS: Windows 11 Pro for Workstations, build 26300
- Server: self-hosted Cloudreve v4

## Steps to reproduce

1. In the server admin panel, set a storage policy's chunk upload concurrency to a value above 2147483647 — e.g. `9999999999`.
2. Mount that user's drive in the desktop client.
3. The sync root registers and connects without error.
4. Open the sync folder in Explorer.

## Actual behaviour

The folder cannot be listed. Log:

```
WARN drive::mounts: Failed to fetch user storage policies id=... error=JSON error: invalid value: integer `9999999999`, expected i32 at line 1 column 114
WARN drive::sync: Failed to enumerate child directory id=... directory=F:\Cloudreve error=JSON error: invalid value: integer `9999999999`, expected i32 at line 1 column 7144
ERROR drive::mounts: Failed to sync paths id=... error=Mount ... sync_group(F:\) encountered 1 error(s):
- F:\Cloudreve: JSON error: invalid value: integer `9999999999`, expected i32 at line 1 column 7144
ERROR drive::mounts: Failed to fetch placeholders id=... error=JSON error: invalid value: integer `9999999999`, expected i32 at line 1 column 7144
```

The last line repeats on every `FetchPlaceholders` callback, i.e. every time the folder is opened.

The offending payload, from `GET /api/v4/file?uri=cloudreve://my`:

```json
"storage_policy":{"id":"K4Uv","name":"...","type":"local","max_size":0,"chunk_concurrency":9999999999}
```

Note that `max_size: 0` is fine — `chunk_concurrency` is the only out-of-range field, and it is not even used for listing files.

## Expected behaviour

One out-of-range value in an auxiliary metadata field should not take down the whole directory listing. At minimum the failure should be visible in the UI rather than only in the log.

## Suggested fix

- Widen `chunk_concurrency` to `u64`/`i64`.
- Make `storage_policy` deserialization tolerant — `#[serde(default)]` plus a clamp, or a lenient wrapper type — so a bad value degrades to a default instead of failing the entire response. The same applies to every other numeric field in this struct.
- Server side, the admin UI accepts values the client cannot represent; validating the range there would prevent the mismatch in the first place.

## Workaround

Set the storage policy's chunk upload concurrency to a small value.

Trace the storage_policy deserialization from GET /api/v4/file?uri=cloudreve://my through drive::sync directory enumeration and the FetchPlaceholders callback; the logs identify drive::mounts as another entry point. Reproduce with chunk_concurrency=9999999999 and inspect how the client handles the auxiliary field. Done means directory listing and placeholder fetching no longer fail because of that value, with any failure visible beyond the log if that behavior is retained.

Written by the indexing model from the issue text.