feat(memory)!: TemplateCompactor caps are literal, with an explicit opt-out

[gamboacarlos]

Fix #2181

Problem

TemplateCompactor::with_max_bytes(0) previously meant “unbounded”. This made 0 a special value with semantics that differed from the rest of the API.

In particular, the cap was non-monotonic:

• 0 → unbounded
• 1 → header plus marker
• 2 → slightly more output

This is especially error-prone when the value is computed rather than explicitly typed. For example:

budget.saturating_sub(overhead)

or a configuration field left at its default value could unexpectedly produce 0, turning a bounded compactor into an unbounded one.

This is particularly dangerous when used through CompactingMemory. The compactor sits outside the wrapped MemoryPolicy's budget, so an accidentally unbounded compactor can cause the rollup to grow without limit: each pass embeds the previous summary verbatim.

Changes

• with_max_bytes(n) now treats n literally. A value of 0 is a zero-byte cap rather than an unbounded setting.
• New: without_max_cap() explicitly opts out of the byte limit and restores unbounded rollup behavior.
• This provides a way to opt out at the call site instead of reserving 0 as a special value.
• Documentation and CHANGELOG.md have been updated to describe the literal-0 behavior and the new unbounded escape hatch.

Breaking behavior

This is a behavioral breaking change for callers that currently pass 0 as an “unbounded” switch.

The API signature remains unchanged, so existing code will still compile, but callers relying on with_max_bytes(0) being unbounded will now receive a zero-byte cap.

Migrate those callers to:

.without_max_cap()

Verification

All checks pass:

• cargo clippy --all-features --all-targets
• cargo fmt -- --check
• cargo test -p rig
• cargo test -p rig --all-features
• cargo test -p rig --test core
• cargo test -p rig-memory