Property-Based Test Generation for a diff algorithm in Go

You are an expert testing specialist with deep expertise in Go engineering.

Generate **property-based tests** for **a diff algorithm** in Go, using Go testing + Testify and a property-testing library (fast-check for JS/TS, Hypothesis for Python, PropEr for Erlang, proptest for Rust, etc.).

**Unit under test:** a diff algorithm
**Language:** Go
**Test framework:** Go testing + Testify
**Driving tool:** Continue.dev
**Convention:** always write tests first (red-green-refactor)

## Why property-based
Example-based tests prove one case. Property-based tests probe thousands and *shrink* failing inputs to their minimal form. For pure logic like parsers, encoders, validators, comparators, and data transformations, they catch bugs example tests miss.

## Properties to identify
For this unit, propose 6-10 properties. Each property must be:
- A universally-quantified claim ("for all valid inputs X, P(X) holds")
- Deterministic
- Fast enough to run thousands of iterations in < 1s

Standard property families to consider:
1. **Round-trip**: `decode(encode(x)) == x`
2. **Idempotence**: `f(f(x)) == f(x)`
3. **Commutativity**: `f(a, b) == f(b, a)`
4. **Associativity**: `f(a, f(b, c)) == f(f(a, b), c)`
5. **Invariants**: structural properties preserved by the function (length, sum, ordering, set-equality)
6. **Oracle**: `f_fast(x) == f_reference(x)` (reference implementation matches optimized one)
7. **Monotonicity**: if `a <= b` then `f(a) <= f(b)`
8. **Error contract**: invalid inputs raise the declared error, nothing else

## For each property, produce
- **Name**
- **Claim** in one sentence
- **Generator** for valid inputs (with bounds, distributions, and any custom shrinking)
- **Test body** in Go testing + Testify + the property library
- **Known edge-case seeds** (e.g. empty, single element, max int, negative zero, NaN, unicode surrogates, empty strings, null bytes)
- **Expected shrinkage** if the property fails (what the minimal counterexample should look like)

## Generator quality rules
- Prefer library-provided generators (`fc.string()`, `hypothesis.strategies.integers`) over hand-rolled
- Always compose generators with explicit ranges, not unbounded defaults
- Document any `pre` filters and argue the filter accepts > 50% of draws (else redesign the generator)
- Seed the RNG deterministically so CI failures reproduce

## Output
1. A short "Properties" section listing each property with its claim
2. A test file body containing all properties
3. A "Run & reproduce" block with:
   - Command to run just these tests
   - Command to re-run with a pinned seed
   - Command to increase iteration count for CI nightly
4. A rollout note: which of these properties is fast enough for every-PR CI vs. nightly-only

## Hard rules
- No property may depend on wall-clock time or environment
- No property may mutate shared state
- Respect always write tests first (red-green-refactor)
- If a property can only be expressed probabilistically, say so explicitly and justify

Present your output in a clear, organized structure with headers (##), subheaders (###), and bullet points. Use bold for key terms.