stdlib: add pow and log with pinned Transcendental plans

Context

The follow-up #41 split off. PR #124 shipped the exact group (abs, copysign, floor, ceil, round, trunc, min, max) plus sqrt. pow and log did not ship, and they are the only remaining functions that need pinned Transcendental plans.

Why these two are different from sqrt

sqrt was allowed to lower to the native instruction because IEEE-754 mandates a correctly-rounded square root — exactly one result is admissible, so every conforming target produces it and three-engine parity holds by the standard rather than by luck. Requirement 8 was amended to permit that single exception, with the reasoning stated in the spec.

No comparable mandate covers pow or log. Their results are implementation-defined, so the ban stands: no platform libm, no LLVM math intrinsic. Each needs its own pinned plan in Transcendental.ts, in the shape the Sin and Cos plans already use.

The blocker this issue inherits

#41's requirements 4–6 demand pinned reduction constants and polynomial coefficients which the issue never supplied. That is the unresolved part, and it is why this is needs-definition rather than ready:

• Which polynomial approximation, to what degree, over what reduction?
• The coefficients themselves, as exact bit values — derived how, and checked against what reference?

Transcendental.ts:3's existing Plan interface is the template: it fixes width, the canonicalNaN bit pattern, the reduction constants (inverseHalfPi, halfPi) and the sine/cosine coefficients as exact bigints, uses a fixed-order Cody-Waite reduction and Horner evaluation, and rounds every intermediate at the target width.

Decide before implementing: derive new coefficients (and say how they are validated), or adopt a published, citable set. Either is fine; guessing is not.

One lesson from PR #124 that applies directly

The correctly-rounded guarantee covers numeric results only. IEEE-754 leaves the sign of a NaN from an invalid operation unspecified, and the hosts genuinely disagree — x86 sqrt of a negative operand sets the sign bit, AArch64's default NaN clears it. PR #124 measured Wasm returning 0xFFF8000000000000 where the evaluator returned 0x7FF8000000000000, and resolved it by screening NaN and negative operands in Silk before the primitive runs.

pow and log have larger invalid domains than sqrt — negative bases with non-integer exponents, zero and negative arguments to log, and the various pow special cases. Enumerate the invalid domain explicitly and decide the result for each case, rather than discovering the disagreements one CI failure at a time.

Requirements

1. pow and log in f32 and f64, each with its own pinned plan.
2. Each plan fixes reduction constants and polynomial coefficients as exact bit values.
3. Each plan rounds every intermediate at the target width, in a fixed order.
4. Neither reaches the platform libm nor an LLVM math intrinsic — sqrt's exception does not extend to them.
5. Identical bits on the evaluator, LLVM and Wasm for every input.
6. The canonical NaN bit pattern for a NaN input, and a decided, tested result for every invalid-domain case.
7. Amend bootstrap-floating-point-scalars through the openspec process.

Acceptance criteria

• The coefficient question above is answered and recorded here before implementation.
• A bit-exact matrix compares all three engines for both functions.
• Every invalid-domain case has a pinned expected bit pattern.
• A check shows neither function reaches libm or an LLVM math intrinsic.
• The libm/intrinsic guard added by #124 is extended to cover them.

Dependencies

None hard. #41's exact group and sqrt landed in PR #124.

Filed by orchestrator run run-r7x1 from the #41 split.

Start with Transcendental.ts:3 and the existing Sin and Cos plans to understand the pinned Plan shape and rounding rules. First resolve and record the polynomial, reduction, coefficient, and validation choices before implementing pow and log. Done means the three-engine bit-exact matrix, invalid-domain cases, and libm/LLVM intrinsic guard all pass, with the openspec amendment completed.