Deal duration too short: Lotus minExpiration requires >= 608,730 epochs

# Deal duration too short: Lotus minExpiration requires >= 608,730 epochs

## Summary

When submitting deals using the Boost CLI, Lotus enforces a sector minimum expiration (`minExpiration`). If the submitted `expiration` is less than this minimum, Lotus will reject the transaction or force the expiration to the minimum value, which can cause the deal to fail or behave unexpectedly.

Observed code location:
- Affected client code: `cmd/boost/deal_cmd.go` (the `duration` flag default is `518400`, equal to 180 days)
- Lotus's minimum expiration calculation (illustrative):
```go
minExpiration := sector.TicketEpoch + policy.MaxPreCommitRandomnessLookback + msd + policy.GetMinSectorExpiration()
if expiration < minExpiration {
expiration = minExpiration
}
```

Under current chain and policy parameters, the difference between `minExpiration` and a typical `expiration` is approximately **608,730 epochs**. Therefore the `--duration` value must be set to at least `608730` epochs, otherwise the proposal may be rejected.

## Reproduction Steps

1. Submit a deal using the Boost CLI (online or offline) without explicitly setting `--duration`, or set `--duration` to a value less than `608730` (for example, the default `518400`).
2. Lotus will reject the proposal or raise an error during processing because `expiration < minExpiration`.

## Actual Behavior

- The proposal may appear to be sent successfully from the client, but Lotus will reject it during on-chain validation or force the expiration to a larger value, resulting in an unexpected deal state.

## Expected Behavior

- The Boost CLI should validate the `duration` locally and show a clear error if it is too short, or the default should be set to a safe value (>= 608,730 epochs) to avoid on-chain failures.

## Suggested Fixes

1. Add a runtime validation for `duration` at the start of `dealCmdAction` in `cmd/boost/deal_cmd.go`:

```go
const minDuration = 608730
if cctx.Int("duration") < minDuration {
return fmt.Errorf("duration too short: Lotus requires at least %d epochs (≈ %.1f days). Please set --duration >= %d", minDuration, float64(minDuration)/2880.0, minDuration)
}
```

2. Optionally, change the default `duration` in `dealFlags` from `518400` to `608730` (or a more conservative value) while keeping the runtime check to handle future chain parameter changes:

```diff
@@
&cli.IntFlag{
Name: "duration",
Usage: "duration of the deal in epochs",
- Value: 518400, // default is 2880 * 180 == 180 days
- },
-+ &cli.IntFlag{
-+ Name: "duration",
-+ Usage: "duration of the deal in epochs",
-+ Value: 608730, // default adjusted to meet Lotus minExpiration
-+ },
Value: 608730, // default adjusted to meet Lotus minExpiration
},
```

3. Add documentation to the README noting that `--duration` is specified in epochs and must meet the chain minimum expiration requirement (currently approximately 608,730 epochs).

## Impact

- The `deal` and `offline-deal` commands in the Boost CLI. Users who do not explicitly set a sufficiently large `--duration` are affected.

## Logs / Error Examples

- The exact Lotus rejection message may vary by version; common symptoms include deal proposals being rejected or failing validation during chain inclusion.

## Notes

- 608,730 epochs is approximately `608730 / 2880 ≈ 211.3` days when using 2880 epochs per day, but the authoritative unit is epochs.

---

Start in cmd/boost/deal_cmd.go, examining dealCmdAction and the duration flag in dealFlags, then compare how deal and offline-deal use it. Reproduce with the default or a value below 608730 and verify that the CLI handles Lotus's minimum expiration clearly; update the relevant README guidance if included in scope.

Written by the indexing model from the issue text.