chore(#512): pin v2.0.0-kernel.3, carrying 0025 and the revised 0018

[gsdali]

Reopens and re-closes #512. kernel.2 was accurate for about an hour.

Why another one

Patch	What changed
0025 (#597, PR #757)	New. GeomFill_Sweep::BuildAll overwrote the measured C1-conversion error with the requested tolerance.
0018 (#555, PR #759)	Revised after upstream review on OCCT#1417.

Neither was in the pinned asset, so build-and-test was resolving a kernel that is not the one this
branch's tests are written against. That is #585.

0018 is the interesting one

In a No_Exception build (which is how we build) the old form already reduced to exactly the new
one, because Standard_ConstructionError_Raise_if compiles to nothing and the duplicate guard below
it was doing all the work. The only revision that can move a compiled result is
Distance() <= theTol becoming SquareDistance() <= aTol2, which differs only by rounding at the
boundary. A 13,534-configuration sweep found 0 differences.

So this pin is not expected to change any answer. It is pinned anyway, because "we measured that it
does not matter" and "the binary contains the source in the tree" are different claims and only the
second one survives someone editing the patch later.

Build discipline

occt-src was reset to clean V8_0_1 before applying, not patched incrementally over the previous
build. The revised 0018 will not stack on the old one, and an incremental apply would either fail
or half-succeed.

Verification

Check	Result
Patches applied	15/15
Stray modifications	0 (50 files owned by a patch, 50 modified)
Objects vs patched sources	sources 22:35, library 23:18
Full suite	5481 tests, 0 failures
Released asset round trip	re-downloaded, checksum recomputed, matches

The round-trip check caught a real defect this time. The first upload was named OCCT3.zip, not
OCCT.xcframework.zip as kernel.1 and kernel.2 are, so the conventional URL returned 404. The
checksum was correct and the archive intact; every consumer would simply have failed to fetch it,
and a checksum-only check would have passed. Renamed the asset, waited out CDN propagation, verified
again.

CLAUDE.md

The patch-count check added with kernel.2 went stale within minutes of being written, which is
exactly what it predicted would happen and why it is phrased as a check rather than a number. Its
note now records that both kernel.1 and kernel.2 drifted, so it does not read as a one-off.

CHANGELOG entry

- Pinned `v2.0.0-kernel.3`, adding patch `0025` (`GeomFill_Sweep` conversion error, #597) and the
  revised `0018` (`GCPnts`, #555) after upstream review. (#512)

SemVer impact

NONE. No Swift API changes, and 0018's revision is measured to change no answer in a
No_Exception build.

[secondmouseAU-bot]

Automated review (medium effort): everything in the actual diff (CLAUDE.md, Package.swift) checked out — patch counts, the release URL, and the new checksum all match the live v2.0.0-kernel.3 asset.

One cross-file finding, not inline-commentable because the file isn't part of this PR's diff:

docs/v2.0.0-plan.md's RESOLVED 2026-08-07 block is now stale. Lines 172-180 still describe the superseded kernel.2/fourteen-patch state ("Cleared by v2.0.0-kernel.2... all fourteen applied... 5442 tests, 0 failures"). That's notable specifically because this block explicitly predicted this PR: "0025 (#597) is already in flight and will reopen it. Watch for it at release: the count in Package.swift's comment and the patch count in Scripts/patches/ must agree, and if they do not, the difference is the set nothing is testing." 0025 did land here, reopening exactly the gap the block described, and this PR re-closes it (15/15 patches, 5481 tests) — but that resolution isn't recorded in the doc, so a reader of this durable reference sees stale verification numbers instead of the current state.

[gsdali]

Finding accepted and fixed, and it is a sharper catch than it looks.

That block predicted this PR. It ended by warning that 0025 (#597) was in flight and would
reopen the gap, and telling the reader to watch the patch counts at release. 0025 landed, 0018
changed alongside it under upstream review on OCCT#1417 so the pin went two stale rather than one,
and the paragraph recording all of that was itself the stale artifact. A durable reference that
correctly forecast its own obsolescence and then did not record it is worse than one that never
forecast anything.

Rewritten to record the reopening and the re-closure rather than swapping one snapshot for another,
because a reference that has been wrong twice in a day is more useful when it says so. Current state
is now in there: fifteen patches, v2.0.0-kernel.3, 15/15 applied with zero stray modifications,
5481 tests.

Added the two things the rebuild taught, which were not in the doc anywhere:

• Reset occt-src to a clean tag before applying. A patch whose content changed will not stack
  on its own earlier form; it fails, or half-applies.
• Verify a published asset by re-downloading it, not by checksumming the local zip. kernel.3's
  first upload was named OCCT3.zip instead of OCCT.xcframework.zip, so the conventional URL
  returned 404 while the checksum was perfectly correct. A checksum-only check passes that every
  time, and every consumer would have failed to fetch.

Thanks for going cross-file on this one. The diff itself was two files and clean; the stale text was
in neither.