fix: seven defects an adversarial audit found, and the gates that missed them

Every one of these was reported ok/clean to the caller while being wrong.

Silently wrong numbers
- selection_filter(min_area) read `entity.dxf.get("area", 0.0)` for SOLID,
  TRACE and HATCH, none of which carry that attribute, so every hatch
  measured 0.0. A 1600 mm^2 hatch was excluded by min_area=1.0 while
  `filtered_by` asserted the filter had run, and COM (which reads ActiveX
  .Area) returned a different selection for the same call. It now answers
  from the measurement `entity_measure` uses, so the two cannot disagree.
- Every headless dimension rendered through ezdxf's bare `Standard` style:
  1.0 mm text with a comma decimal marker, against ISO 3098's 2.5 mm minimum
  and ISO 129's point -- while the document header itself said $DIMTXT 2.5.
  `ezdxf.new(setup=True)` is not the fix; measured, it renders a 100 mm
  dimension as "10000". The attributes are now stored explicitly.
- Saving writes `dimrnd = 0.0` onto the Standard style, and ezdxf applies
  `xround(value, dimrnd)` whenever the attribute is present at all --
  `xround(33.333, 0.0)` is 33. So on any reopened file, including one this
  server saved, every dimension was rounded to a whole unit before DIMDEC
  formatted it: a 12.75 mm feature dimensioned 13. AutoCAD means DIMRND 0 as
  *no* rounding; the sentinel is now discarded at every load site, and a real
  0.5 mm rounding is left alone.
- The DIM* header fold gave out-of-range values teeth they did not have when
  they died in the header: dim_decimals=-1 returned ok and then killed the
  next dimension with `ValueError: Format specifier missing precision` from
  inside ezdxf, and 40 printed forty digits of float noise onto the sheet.
  Ranges are now AutoCAD's own (DIMDEC 0-8, DIMZIN 0-15, lengths positive).

Security
- security.py recorded the policy as "sanitize_command and sanitize_lisp each
  have exactly ONE caller ... the policy is scoped to the CHANNEL". The
  premise was false. `_ensure_linetype_loaded` and `ComBackend.linetype_load`
  build `_-LINETYPE _LOAD {name} {file}` and hand it to SendCommand, which
  treats a newline and ';' as segment separators -- so a `linetype=` argument
  carrying either injected further AutoCAD commands, and the 36-verb denylist
  never saw that channel. Guarded with the DXF symbol-name rule (the
  injection characters fall out of it rather than being enumerated) plus
  validate_path for the file argument, which was also the one path-taking
  tool reaching the filesystem unchecked. The policy comment is corrected.

Gates that could not see
- drawing_critique returned zero issues on a quarantined document: all seven
  checks wrapped their backend call in a bare `except Exception`. CLAUDE.md
  rule 7 makes that call the gate an agent is told to trust. Only the
  quarantine now escapes; an ordinary broken check still degrades.
  `_check_dimension_legibility` also read `_doc` directly from the event loop
  thread, missing the gate and performing exactly the unsynchronised access
  the quarantine exists to prevent. `construction_clear` answered
  "deleted: 0" -- there was nothing to clear -- for the same reason.
- The iso128 focus checked layer lineweights only, so a sheet lettered at
  1.0 mm critiqued clean. It now reads the effective dimension height and
  separator, header-then-style, in the order the renderer resolves.
- check_doc_numbers.py derived five values it never checked, and those were
  the ones that had drifted. The collected-test count (README said 1274, the
  tree had 1369) and the A/B pass-rate and Fixed columns are now gated.
- benchmarks/README.md's v1.4.0 table was impossible on its face -- 21
  passing plus 5 fixed is 26, not 24 -- and contradicted the report it
  linked, because `ab-v1.4.0-vs-v1.5.0.json` was regenerated from a tree that
  already carried the dimension fixes and so never measured the v1.5.0 tag.
  Replaced with a real run: ab-v1.4.0-vs-v1.5.1.json, 21/26 -> 26/26.

Release gate
- release.yml ran one ubuntu/3.11 lane, so a Windows-only defect could reach
  PyPI with no Windows job having executed. That is not hypothetical: v1.5.0
  shipped `except pywintypes.com_error` raising NameError wherever pywin32 is
  absent. It now runs the same three lanes as ci.yml, Windows included.

1368 passed, 1 xfailed. ruff clean. Tool inventory and all 16 gated document
numbers match the tree.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

benchmarks/README.md

@@ -183,7 +183,6 @@ for i in 1 2 3; do
   python -m benchmarks.perf_suite --out /tmp/on-$i.json
   EZDXF_CALL_TIMEOUT=0 python -m benchmarks.perf_suite --out /tmp/off-$i.json
 done
-git worktree remove --force /tmp/wt-v140
 ```
 
 ## Correctness A/B suite
@@ -202,17 +201,39 @@ python benchmarks/compare_versions.py v1.0.0     # vs a tag/ref
 python benchmarks/compare_versions.py --json results.json
 ```
 
-### Result — v1.5.0 vs v1.4.0 (release gate)
+### Result — v1.5.1 vs v1.5.0 (release gate)
 
 26 checks, ezdxf backend, one subprocess per check. Machine-readable report:
-[`results/published/ab-v1.4.0-vs-v1.5.0.json`](results/published/ab-v1.4.0-vs-v1.5.0.json).
+[`results/published/ab-v1.5.0-vs-v1.5.1.json`](results/published/ab-v1.5.0-vs-v1.5.1.json).
+
+| Version | Checks passing | Pass rate | Fixed | Regressed |
+|---------|----------------|-----------|-------|-----------|
+| **v1.5.0** (baseline)     | 24 / 26 | 92.3 % | — | — |
+| **v1.5.1** (this release) | 26 / 26 | 100 % | 2 | **0** |
+
+v1.5.0 fails `diameter_dim_measures_the_diameter` and
+`radius_dim_ignores_the_leader_length`: it has both methods and gets both
+wrong. That is the defect 1.5.1 exists to fix and the reason 1.5.0 is yanked.
+
+### Result — this release vs v1.4.0
+
+Same suite, older baseline:
+[`results/published/ab-v1.4.0-vs-v1.5.1.json`](results/published/ab-v1.4.0-vs-v1.5.1.json).
 
 | Version | Checks passing | Pass rate | Fixed | Regressed |
 |---------|----------------|-----------|-------|-----------|
 | **v1.4.0** (baseline)     | 21 / 26 | 80.8 % | — | — |
-| **v1.5.0** (this release) | 26 / 26 | 100 % | 5 | **0** |
+| **v1.5.1** (this release) | 26 / 26 | 100 % | 5 | **0** |
 
-The pass rate is against the 26-check v1.5.0 suite; v1.4.0 passed 21/21 of the
+> This row used to read `v1.5.0 | 24 / 26 | 92.3 % | 5`, which was impossible on
+> its face — 21 passing plus 5 fixed is 26, not 24 — and it contradicted the
+> report it linked. The cause is worth recording: the file named
+> `ab-v1.4.0-vs-v1.5.0.json` was regenerated from a tree that already carried
+> the dimension fixes, so it never measured the v1.5.0 *tag*. The v1.5.0 tag
+> really does score 24/26, which is what the v1.5.0-baseline table above
+> reports. This table now names the tree it actually measured.
+
+The pass rate is against the 26-check current suite; v1.4.0 passed 21/21 of the
 checks that existed when it shipped. The five splits into two kinds, and the
 difference is the whole reason this lane distinguishes `miss` from `fail`:
 
@@ -222,10 +243,11 @@ difference is the whole reason this lane distinguishes `miss` from `fail`:
   having the method (`miss → pass`). They are in the suite because all three
   broke during v1.5.0 development and nothing outside their own unit tests
   would have caught it.
-* **Two are repaired defects.** v1.4.0 *has* `dimension_diameter` and
-  `dimension_radius` and gets them wrong (`fail → pass`): `leader_length`, a
-  text placement, was being measured as geometry, so at default settings every
-  diameter callout came out 2 × `leader_length` too large.
+* **Two are repaired defects.** v1.4.0 *and v1.5.0* both have
+  `dimension_diameter` and `dimension_radius` and both get them wrong
+  (`fail → pass`): `leader_length`, a text placement, was being measured as
+  geometry, so at default settings every diameter callout came out
+  2 × `leader_length` too large. Only 1.5.1 passes them.
 
 The 21 pre-existing checks are unchanged and all still pass: the discovery
 layer, `cad_batch`, the 19-module contract split, the layout/viewport family