Release v2.12.0

Added

• A test now fails when a configuration section is added without documenting it.
  configs-for-run.rst still opens by saying a run config has "at most ten distinct
  sections" while the schema has fourteen: ncpu, ring_cure and postcure_repair have
  never been written up. The new test carries those three in a named list so the
  existing debt does not block the suite, fails on any new undocumented section, and
  fails again if one of the three is documented and left on the list.

• htpolynet piercings reports any bond threaded through a ring in a finished
  network. Since 2.11.4 a ring cure can refuse to create a threading, and there was
  no way to ask whether one is there. That asymmetry is the reason this exists: a
  preventive check whose effect cannot be measured with the same tool is hard to trust,
  and every number that justified those filters came from scripts outside the package.
  Nothing about it is chemistry-specific --- any network built by dragging monomers
  together can thread a bond through a ring.

  It takes a top and gro pair like make-viz, reports each piercing with the ring's
  composition, whether the piercing bond belongs to a residue of the ring, the offset of
  the crossing from the ring centre in nm and as a fraction of the ring radius, the
  angle to the ring normal, and the bond length; it correlates those against bonds too
  long to be bonds, which in measured data are the same set. -json writes the
  findings out. It exits 1 when it finds any, so it can gate a pipeline.

  The geometry moved to htpolynet.geometry.piercing, shared with the ring cure's own
  filters so that a measurement and the thing it measures cannot drift apart.

  Validated against 12 independently measured builds (8 affected, 10 piercings):
  counts agree on all 12, including the four clean ones, and both interlocked cases are
  found with both halves. Bond lengths agree to the last digit, offsets within
  0.001 A, angles within 0.03 degrees. Four of those piercings are in the test suite as
  fixtures, atom-for-atom.

  That comparison found two defects in the reference data rather than in this code ---
  atom indices off by one, and a fraction divided by a mean rather than a maximum
  centre-to-vertex distance --- both since corrected upstream. The index error was
  findable only by testing whether the reported ring was a closed cycle in the topology,
  which is the check worth keeping in mind when two implementations are compared: agree
  with the data, not with the other detector.

  The angle is reported as angle_from_normal, and 0 degrees means the bond runs
  straight through, perpendicular to the ring plane. The report says so in a legend,
  because the obvious reading of such a field is the opposite one.

  Documented in the user guide, in the subcommand table and with a section of its own,
  alongside a note that a threaded ring is a topological defect rather than a strain
  relaxation removes: if one is found in a finished build, rebuilding with the ring-cure
  filters on is the remedy and there is no post-hoc repair.

  Image before you average. Every ring atom is brought into one periodic image
  before the centroid is taken. Without that, a ring straddling a boundary gets a
  centroid in the middle of the box and a triangle fan spanning the cell: measured here
  on a 2 nm box, a 0.14 nm ring reads as 0.938 nm about a centre a full box-half away,
  which reports a piercing for nearly everything nearby. A detector written without it
  found 212 piercings in an uncured melt, where the answer is zero by construction, and
  about 15% of rings straddle a boundary in a real system. The test suite covers that
  case, its converse, over-long piercing bonds of 2.4 to 3.2 A, composition classified
  on the whole ring rather than on a residue count or a truncated printout, and two
  interlocked rings.