refactor(einteger): split einteger into core / manipulators / iostream / debug (#1334) - #1457

First type of Phase 2 group 5b (#1455), the elastic types.

core.hpp        55,183 lines / 284 headers / 0 I/O-family
einteger.hpp    73,655 lines / 369 headers / 5 I/O-family  (was 94,467 / 395 / 5)

Zero I/O-family headers is met. Under-45,000 lines is not, and reporting the
number rather than moving the bar: native/ieee754_core.hpp is 43,486 lines on
its own (already 0 I/O), and einteger needs two functions from it --
extractFields and ieee754_parameter. The narrower header those live in,
extract_fields.hpp, is not self-contained; it leans on ieee754_core.hpp's
include order. That is the substrate's to fix, not this PR's.

The regex was the whole of the I/O problem

parse() classified its input with four std::regex patterns, compiled on every
call. alone is 78,114 preprocessed lines and pulls ,
and . parse() cannot leave the core -- assign(const std::string&) is
built on it, the layer contract -- so the patterns became four hand-written
matchers in einteger_detail, each accepting exactly its pattern's language under
std::regex_match's whole-string semantics. None needs backtracking: a sign run
can never swallow the '0' after it.

That is also why the UMBRELLA dropped 20,812 lines: the regex is gone for every
einteger user, not only core users.

The proof is a new regression test, conversion/parse_grammar.cpp, which keeps the
original patterns as its oracle: every byte value 0..255 in 144 grammar contexts,
plus every string up to length 4 (level 1), 5, 6 and 7 (level 4) over a 19-symbol
alphabet covering each character class and its neighbours. Ten single-point
mutations of the matchers -- each range bound, the '0'-only decimal, the "0b"
minimum, 'X', the apostrophe, the sign set, the octal radix marker -- are all
caught at level 1.

The rest of the split

• showLimbs()/showLimbValues() build text with a stringstream: declared in the
  class, defined out-of-line in debug.hpp, the shape blocktriple's got in refactor(internal): move blocktriple's introspection out of the core header (#1334) #1388.
• convert_to_string (takes fmtflags), operator<<, operator>> -> iostream.hpp,
  which includes only core.hpp: operator>> calls parse(), which is core.
• to_binary, to_hex -> manipulators.hpp, beside type_tag.
• reduce()'s divide-by-zero and assign()'s parse failure -> fprintf to stderr.
  assign() writes the text with fwrite, not %s: std::cerr wrote every byte of
  the string, embedded NULs included, and the differential checks that.
• native/ieee754.hpp -> native/ieee754_core.hpp in the impl; the umbrella keeps
  including ieee754.hpp, which used to arrive through the impl.
• EINTEGER_ENABLE_LITERALS and EINTEGER_THROW_ARITHMETIC_EXCEPTION default in
  einteger_impl.hpp (layered cores do not define their own *_THROW_ARITHMETIC_EXCEPTION guard #1436).
• einteger_fwd.hpp and numeric_limits.hpp now include what they use.
  numeric_limits.hpp includes the fwd, not the umbrella: no areal-style cycle.

One regression, caught by the gate

Knuth division calls nlz(). It used to arrive through ieee754.hpp ->
native/integers.hpp, and -fsyntax-only on core.hpp was clean without it -- the
call sits in a template body. The instantiating core gate failed to compile. The
impl now includes native/integer_core.hpp, the I/O-free half that declares it.

Verification

• Layer gates, gcc 13.3 and clang, -Wall -Wpedantic: core.hpp alone,
  core + manipulators, core + iostream, core + debug each compile, link and run,
  and each INSTANTIATES every function its layer defines (manipulator templates that no test instantiates: type_field(bfloat16) and components(areal) do not compile #1453), for all three
  block types. The core-only TU has 0 I/O-family headers under g++ -H.
• Self-containment: core, fwd, impl, exceptions, numeric_limits, manipulators,
  iostream, debug and the umbrella each compile standalone, 0 errors and 0
  warnings, both compilers.
• 22 targets built and run green on both compilers: all 14 eint_* targets
  including the new eint_parse_grammar, plus every consumer of
  verification/dyadic_exact.hpp (elreal round_to, reference_digits and
  exact_value_oracle; ereal exact_value_oracle; the qd_cascade and td_cascade
  addition oracles; expansion eft_exactness and api). multifile, which links
  einteger with nine other types across TUs, builds and runs on both.
• Differential against main, from a worktree, for all three block types: parse()
  over every string up to length 5 on a 14-symbol grammar alphabet (579,195
  each); 1,600 long random literals through parse, assign and operator>>; 300
  random operand pairs through + - * / % <<= >>=, each result rendered by
  operator<< under nine stream states, to_binary, to_hex, type_tag, showLimbs,
  showLimbValues, convert_to_string and the native conversions; and every stderr
  diagnostic, including assign() of a string with an embedded NUL. 29,939,416
  bytes of stdout and 423 of stderr byte-identical -- old vs new on gcc, old vs
  new on clang, and gcc vs clang. The sweep runs in 1.0 s on this tree against
  3m06s on main; the four regexes were being compiled on every parse() call.

Found, not fixed: showLimbs() calls to_binary(limb, sizeof(BlockType) * 8, true)
against the signature (number, bNibbleMarker, nbits), so it prints one bit per
limb. Identical on main, and never called; gcc's -Wint-in-bool-context flags it
the moment the gate instantiates it. #1456.

Part of #1455.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NazYbxaii2XXVzQeQKMDTs

Summary by CodeRabbit

• New Features

  • Added stream input and output support for einteger values.
  • Added decimal, octal, and hexadecimal formatting with sign, prefixes, width, fill, and alignment options.
  • Added binary and hexadecimal display helpers with optional digit separators.
  • Invalid input during stream extraction now sets the stream failure state and reports an error.
  • Added debugging views for inspecting stored integer values as binary or radix-based text.

• Bug Fixes

  • Improved parsing reliability across binary, octal, decimal, and hexadecimal number formats.