review: --max-tools 10-29 is accepted but silently ignored

## Problem

In current `main` and v1.9.4, `ocr review --max-tools N` accepts and normalizes positive values down to a documented minimum of 10, but values from 10 through 29 do not affect the embedded review template whose default is 30.

The two code paths disagree:

- `validateReviewOptions` clamps `1..9` to 10, and the review flag help says `max tool call rounds per file (0 = template default; min 10)`.
- `loadCommonContext` applies the value only when `maxTools > tpl.MaxToolRequestTimes`.

Therefore, `--max-tools 10`, `15`, and `20` all still run with 30 rounds. There is no warning that the supplied cap was ignored.

This matches the historical behavior documented in #20, but it conflicts with the current review CLI contract and prevents operators from using the flag as a cost/latency guard.

## Why it matters

Review cost can be dominated by accumulated per-file tool rounds rather than diff size. A small ambiguous file that consumes the full 30-round conversation can cost more than many straightforward files. A positive value described as a maximum must either lower the effective round limit or fail clearly; silently retaining 30 makes cost controls appear active when they are not.

## Proposed contract

For `ocr review`:

- `--max-tools 0`: use the embedded template default.
- `--max-tools N` where `N >= 10`: set the effective per-file maximum to exactly `N`.
- `1..9`: keep the existing clamp-to-10 behavior, or reject it explicitly.
- Negative values: keep rejecting them.

If scan intentionally needs raise-only behavior, it can retain that separately with its existing explicit help text.

## Acceptance test

With an embedded template value of 30, prove the resolved review template is:

- 30 when CLI value is 0
- 10 when CLI value is 10
- 20 when CLI value is 20
- 40 when CLI value is 40

The effective value should also be visible in JSON/session diagnostics so callers can prove which cap actually ran.

Start at validateReviewOptions and loadCommonContext, then trace how the embedded review template resolves the max-tools value. Add coverage for CLI values 0, 10, 20, and 40 against a template default of 30, and verify that the effective value is exposed in JSON or session diagnostics.

Written by the indexing model from the issue text.