Define opt-in retry and backoff policies for HTTP queries

## Summary

Define opt-in retry and backoff policies for HTTP queries when query-specific requirements justify framework support.

Queries intentionally do not retry a failed generation automatically today. Applications can invalidate the key after an error or implement retry inside the fetcher. Generic command retry also exists, but it does not define query-cell policy.

A built-in query policy should be added only when concrete requirements go beyond those escape hatches, such as `Retry-After`, error classification, or reproducible jitter.

## Design requirements

- The default remains no automatic retry.
- Retrying one shared cell must not duplicate work across subscribers.
- A failed generation must never form a same-generation tight loop.
- Cancellation, invalidation, inactive retention, and refetch intervals must compose predictably.
- If jitter is supported, its deterministic-test strategy must be explicit; do not add a general application clock or RNG registry.

## Acceptance criteria

- [ ] Record at least one concrete HTTP-specific use case not adequately served by fetcher-owned retry.
- [ ] Define retryable errors, attempt limits, delay/backoff, and `Retry-After` precedence.
- [ ] Preserve the current no-retry default.
- [ ] Paused-time tests cover success, exhaustion, invalidation, multiple subscribers, and cancellation.
- [ ] Documentation explains when to use command retry, fetcher-owned retry, or query policy.

Start by comparing the existing command-retry and fetcher-owned retry escape hatches with the query-cell requirements. Record a concrete HTTP use case, then define error classification, attempt limits, backoff, Retry-After precedence, cancellation, and subscriber behavior. Done means the no-retry default remains, paused-time tests cover the listed cases, and documentation explains which retry mechanism to use.

由索引模型根据 Issue 内容生成。