refactor(elreal): split elreal into core / manipulators / iostream (#1334) - #1465

…1334)

Fourth and last type of Phase 2 group 5b (#1455).

    core.hpp     94,744 lines / 413 headers / 1 I/O-family (<ostream>)
    elreal.hpp  116,357 lines / 524 headers / 5 I/O-family  (was 142,929 / 705 / 5)

THE CORE REACHES 1 OF 5, NOT 0, AND NO HEADER SPLIT CAN FIX IT. Reporting the
number rather than moving the bar: ZBCL nodes are std::shared_ptr and the thunks
std::function, and libstdc++ 13's <memory> itself includes <ostream> -- 53,429
lines, before a line of Universal. <iostream>, <sstream>, <iomanip> and <istream>
are all gone. This is the same kind of floor <complex> sets for every mathlib
(it pulls <sstream>): a property of the standard library, not of the layering.
Getting under it means replacing shared_ptr in the co-list, which is a design
change, not a layering one. The line count is set by the same things: <memory>,
<functional> and integer's core (the 256-bit block exponent) are 80,677 lines
together.

elreal's own code was already clean

Its text was already confined to manipulators.hpp and block_manipulators.hpp.
What put all five I/O-family headers into every elreal translation unit was the
types it is built from, reached by their UMBRELLAS:

- block.hpp included integer/integer.hpp for exp_t, the integer<256> exponent
  (#1061) -> integer/core.hpp.
- round.hpp included dd.hpp, qd.hpp and cfloat.hpp for round_to's targets ->
  their cores. round_to only converts into those types; it never formats them.

All four have had cores since group 4; this is the substrate-first rule paying
out. Two consequences the build found:

- block_manipulators.hpp streams the integer<256> exponent (`s << b.exp`), and
  operator<< for integer is in integer's text layer. It used to arrive with the
  integer umbrella through block.hpp; block_manipulators.hpp now includes
  integer/iostream.hpp itself.
- qd's core does not define the ldexp its ulp() calls, so including qd/core.hpp
  warns "used but never defined" in every elreal translation unit, and a
  core-only TU that calls ulp() fails to link. That is qd's bug, not elreal's:
  fixed in #1464 (#1462). Until it lands, these builds carry that one warning.

The split

- core.hpp: fwd, block, the ZBCL machinery (zbcl, helpers, block EFTs, threeAdd,
  series, sum, infsum), the streaming and eager operators, the elreal class
  facade, numeric_limits and elreal_traits. The traits used to be reached only
  through manipulators.hpp.
- operator<< and operator>> -> iostream.hpp, which includes only core.hpp:
  both go through a host double.
- manipulators.hpp keeps to_components / to_binary / to_triple / type_tag /
  nonfinite_tag and includes core.hpp.
- The mathlib and round.hpp are I/O-free as they are and stay separate facets,
  as in every other type. A core translation unit can add either one and still
  have only <ostream>: mathlib.hpp 95,440 lines, round.hpp 103,011, 1 I/O each.
- ELREAL_THROW_ARITHMETIC_EXCEPTION already defaulted in exceptions.hpp, not
  the umbrella, so #1436 needed nothing here.

Verification

- Layer gates, gcc 13.3 and clang, -Wall -Wpedantic: core.hpp alone, core +
  manipulators, core + iostream, core + attributes, core + mathlib and core +
  round each compile, link and run, and each INSTANTIATES what it defines
  (#1453). The core gate drives the class facade (every operator, the
  SpecificValues, precision guard, approx, limbs, the native conversions,
  numeric_limits) and the ZBCL layer under it (from_native, add, mul_online,
  div_online, negate) on both the double and float hosts. The manipulator gate
  calls every elreal and every block manipulator, the round gate round_to into
  double, float, dd, qd and a cfloat. The only diagnostic is qd's (#1462).
- Self-containment: every header in number/elreal/ and number/elreal/math/
  compiles standalone, 0 errors, both compilers; the only warning is qd's.
- 51 targets built and run on both compilers: all 50 el_* targets PASS, and
  elreal_demo_thousand_digit_sqrt runs to completion.
- Differential against main, from a worktree: 60 random operand pairs on each
  of the double and float hosts through + - * / unary minus and the compound
  operators, every result rendered by operator<< under four stream states, every
  elreal manipulator, the attributes, the native conversions, and the
  manipulators of each of its first four blocks (1,910 block renderings); the
  non-finite SpecificValues, numeric_limits, divide-by-zero, operator>> on a bad
  token; the whole class-level mathlib and five constants; and round_to into
  double, float, dd, qd and cfloat<16,5> for 39 quotients under all four
  rounding modes. 646,118 bytes of stdout byte-identical -- old vs new on gcc,
  old vs new on clang, and gcc vs clang; every run exits 0 with empty stderr.
  elreal_demo_thousand_digit_sqrt's output is identical to main's too, except
  its wall-clock timings.

Found, not fixed -- identical on main:

- elreal(SpecificValue) hard-codes double magnitudes: elreal<float>(maxpos)
  trips from_native's assertion (1.0e308 overflows the float host) and minpos
  becomes zero. #1463. The gates and the differential construct maxpos and
  minpos on the double host only, for that reason.

Part of #1455.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NazYbxaii2XXVzQeQKMDTs