Upgrade Docxodus to v7.0.0 and expose its comparison-engine flag

[JSv4]

Upgrades the vendored Docxodus submodule from v5.4.2 to v7.0.0 and exposes v7.0.0's new
--engine=wmlcomparer|docxdiff selector as an engine= kwarg on DocxodusEngine.

engine = DocxodusEngine()
engine.run_redline("Reviewer", original, modified)                     # wmlcomparer (default)
engine.run_redline("Reviewer", original, modified, engine="docxdiff")  # new IR engine

wmlcomparer stays the default. When engine is omitted no --engine flag is emitted at all,
so the argv is byte-identical to the pre-v7 one.

The upgrade drags .NET 10 in with it

Docxodus v7.0.0 retargets net8.0 → net10.0. That reaches past the submodule:

• Root global.json → SDK 10.0.0. It governs SDK selection because dotnet resolves
  global.json from the working directory, not the project path, so docxodus/global.json
  is never consulted by our builds.
• The three CI dotnet-version pins → 10.0.x.
• build_differ.py hardcoded net8.0 in its publish path. The two engines now target different
  frameworks, so ENGINES carries a per-engine tfm.

Only one SDK is provisioned. The .NET 10 SDK builds the net8.0 ooxmlpowertools project
self-contained; its binary still reports Revisions found: 9. Verified locally on linux-x64
and cross-built for linux-arm64. The Windows and macOS wheel builds are exercised for the
first time by this PR's CI.

Contributors now need a .NET 10 SDK — a stock .NET 8 box can no longer build the Docxodus
engine at all. Documented in the README and developer guide.

docxdiff silently drops three settings, so Python rejects them

On the docxdiff branch, DocxCompare.ToDocxDiffSettings maps only a subset of
WmlComparerSettings. It drops detail_threshold, simplify_move_markup, and
detect_format_changes — the CLI accepts them, prints no diagnostic, and produces output as if
they were never passed. Confirmed empirically: --engine=docxdiff --detail-threshold=0.9
yields the same result as --engine=docxdiff alone.

Passing any of those three alongside engine="docxdiff" now raises ValueError before we shell
out. Rejection is on key presence, regardless of value: two of the three are no-ops at their
defaults, so a value-sensitive rule would raise for detect_format_changes=False but not for
detect_format_changes=True — a worse contract than "naming a WmlComparer-only knob while
asking for docxdiff is an error."

docxdiff does honour detect_moves, case_insensitive, conflate_spaces,
move_similarity_threshold, move_minimum_word_count, and date_time.

The two engines report different revision counts

On tests/fixtures/, wmlcomparer finds 9 revisions and docxdiff finds 11. Different
algorithms, both correct. Both counts are asserted: the 9 guards against an accidental default
flip, the 11 against a silent no-op where --engine never reached the binary.

Also scoped the README's move-detection warning to WmlComparer. It told every caller to pair
detect_moves with simplify_move_markup, but docxdiff honours the former and rejects the
latter, so a docxdiff user following the docs hit a ValueError with no available mitigation.
DocxDiff renders moves natively; whether Word's ID-collision bug affects its move markup is
untested and the docs no longer imply either way.

Testing

40 tests pass. Version bumped 0.2.1 → 0.3.0 (the bump also re-keys the binary-extraction
cache, which is keyed by package version).