[Feature] Fix auto_clear_time conversion and wait_interval boundary

**Feature Category**
- [ ] Sandbox
- [ ] Actions
- [ ] Deployments
- [x] SDK & API
- [ ] Envhub
- [ ] CLI
- [ ] Performance & Optimization
- [ ] Documentation & Examples

**Problem Statement**
In `Sandbox.create()`, `auto_clear_time` and `auto_clear_time_minutes` are calculated via plain float division (`auto_clear_seconds / 60`), which can produce fractional minutes (e.g., 90 seconds → 1.5 minutes). The server-side API expects an integer value in minutes, and a float may cause unexpected truncation or rejection.

Additionally, `wait_for_process()` does not enforce that `wait_interval` is smaller than `auto_clear_seconds`, which can lead to the sandbox being auto-cleared before the next status check happens.

**Proposed Solution**
1. Use `int(math.ceil(auto_clear_seconds / 60))` to ensure the minutes value is always an integer rounded up, preventing premature sandbox cleanup.
2. Add an upper bound `wait_interval = min(auto_clear_seconds - 2, wait_interval)` to guarantee at least one check occurs before the sandbox auto-clears.

**Detailed Feature Description**
- Import `math` module in `rock/sdk/sandbox/client.py`
- Replace `self.config.auto_clear_seconds / 60` with `int(math.ceil(self.config.auto_clear_seconds / 60))` for both `auto_clear_time` and `auto_clear_time_minutes` fields
- Add `wait_interval = min(self.config.auto_clear_seconds - 2, wait_interval)` in `wait_for_process()` to cap the polling interval

Start in rock/sdk/sandbox/client.py by reading Sandbox.create() and wait_for_process(). Check the auto_clear_time and auto_clear_time_minutes conversions and the polling interval behavior; done means fractional-minute values are rounded up to integers and wait_interval allows a status check before auto-clear.

Written by the indexing model from the issue text.