[terrelln]

Full-format dictionaries may contain repeat offsets into content discarded by the short-cache CDict limit or the general index limit. Revalidate all three repcodes after loading the retained suffix and enforce the same bound before attaching a CDict, preventing wrapped dictMatchState indices and wild reads.

Add regression coverage for 20 MiB dictionaries, every repcode slot, fast/dfast levels, deferred and streaming dictionary loading, the short-cache boundary, and valid non-truncating controls.

NOTE: This will reject dictionaries that have repcodes > 16 MiB when using the short-cache CDict. But I think this is reasonable, and if it becomes a problem in the future, we can fix it then, as it is an encoder-side only limitation.

[Cyan4973]

The new check at the end of ZSTD_loadZstdDictionary() also runs when the dictionary is loaded directly into a CCtx.
In this case, the window may have been reduced by overflow correction,
so a CCtx which has already compressed a few GB can reject a valid dictionary that a fresh CCtx would accept.
The CCtx path already discards out-of-range repcodes, so this check is only needed for the CDict:
I would limit it to tfp == ZSTD_tfp_forCDict.

minor: the + 1 in tests/fuzzer.c:1130 aligns src on rep - 1, so the boundary cases never actually encode a match at rep.

minor: when the dictionary is rejected, it shows up as a NULL CDict, which the CLI reports as "Allocation error". That's a bit misleading.

[terrelln]

• Fixed the issue with overflow correction & added a test case that catches the bug.
• Fixed the CLI allocation error messaging
• Fixed the test case