fix: guard token-count divisions against ZeroDivisionError (#183)

[ousamabenyounes]

What does this PR do?

Fixes #183

compress_prompt_llmlingua2 and structured_compress_prompt compute target_token / n_original_token (and its siblings) in four places. Under certain structured-compress payloads — e.g. a compress_json call where every key is force-reserved, or the context after tag stripping resolves to empty strings — the denominator collapses to zero and the call dies with ZeroDivisionError: float division by zero before the user ever sees a compressed result. The reporter hit this on the exact repro in the issue.

Fix

Wrap each division in an if n > 0 guard that falls back to rate = 1.0 (keep everything) when there are no source tokens to compress. The fallback preserves the semantic meaning of "there is nothing to compress here" without swallowing the error silently — downstream code handles `rate >= 1.0` correctly.

Sites patched

File / function	Division before	Division after
`structured_compress_prompt` (L387)	`target_token / sum(context_tokens_length)`	guarded by `sum > 0`, else `1.0`
`compress_prompt_llmlingua2` (context-level path, L839)	`context_level_target_token / n_original_token`	guarded by `n_original_token > 0`
`compress_prompt_llmlingua2` (context-level path, L870)	`target_token / n_reserved_token`	guarded by `n_reserved_token > 0`
`compress_prompt_llmlingua2` (token-level path, L932)	`target_token / n_original_token`	guarded by `n_original_token > 0`

The two other divisions in the same function (`n_original_token / n_compressed_token` for `ratio`) already had the `1 if n_compressed_token == 0 else …` guard — left untouched.

Before submitting

• This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Was this discussed/approved via a Github issue? Please add a link to it if that's the case — [Bug]: ZeroDivisionError: float division by zero upon using compress_json with use_llmlingua2 #183.
• Did you make sure to update the documentation with your changes?
• Did you write any new necessary tests? — see `tests/test_issue_183.py` (8 new tests: 4 runtime guard tests + 4 AST-based pins on the source tree, all passing in ~5s, no network / model download).

Verification

• Baseline: 2 tests pass, 3 tests fail with a pre-existing `ValueError: too many values to unpack (expected 2)` in `iterative_compress_prompt` (transformers DynamicCache API change — unrelated to this PR).
• Post-fix: 2 baseline tests still pass + 8 new tests pass, same 3 pre-existing failures — zero regressions.

Generated by Claude Code
Vibe coded by ousamabenyounes