refactor(types): NotSummed twin uses explicit per-variant mapping

Phase 1.6 — revert the Phase 1.5 mask widening. The NotSummed family
returns to its original 4-bit prefix `0xb0` / range `0xB0..=0xBF`. The
five legal sum-tree inner types are mapped to twin slots explicitly,
1-at-a-time, instead of via the `prefix | base` bitwise formula:

  SumTree (base 4)               -> 180  (0xB4)
  BigSumTree (base 5)            -> 181  (0xB5)
  CountSumTree (base 7)          -> 183  (0xB7)
  ProvableCountSumTree (base 10) -> 186  (0xBA)
  ProvableSumTree (base 17)      -> 177  (0xB1)

Existing twins return to their original discriminant values; only the
new ProvableSumTree slot is freshly assigned. Pre-shipping V1, so this
discriminant churn is fine.

WHY EXPLICIT MAPPING

`prefix | inner_byte` can only generate twin slots when the inner
discriminant fits in the prefix's complement nibble. For ProvableSumTree
at base 17, the formula `0xb0 | 17` would produce `0xB1` AND then
`disc & 0x0F` would invert it back to base 1 (Reference) — a collision.
Widening the mask to 5 bits in Phase 1.5 rebased every existing twin
discriminant; reverting to per-variant mapping keeps the historical
values stable while still allowing arbitrary new slot assignments.

CONSEQUENCES

- `NOT_SUMMED_TWIN_PREFIX` stays as a const but is now only a family-range
  marker, never composed with a base byte.
- `NOT_SUMMED_BASE_MASK` removed — no remaining callers.
- `is_not_summed()` back to `& 0xf0 == 0xb0`.
- `base()` for NotSummed now uses an explicit per-variant match.
- `from_serialized_value` NotSummed branch uses an explicit
  `inner_byte → twin_variant` match.

NonCounted is unaffected — it still uses the bitwise formula because all
its bases fit cleanly in the low 5 bits under `0x80`.

Workspace cargo test --all-features green (2881 tests).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: QuantumExplorer