Establish complex-coordinate and projective semantics

[isomorphisms]

Purpose

Establish the complex/projective structural layer on the now-merged quadratic/Hermitian work without turning the exact Gaussian-integer fixture into the general complex-number hierarchy.

Type boundary

• ComplexCoordinates complex n carries the coordinate count in the type and represents the structural shape of C^n for a concrete complex carrier.
• ComplexProjectivePoint complex n carries a nonzero homogeneous representative with exactly n + 1 complex coordinates.
• projective equality is not raw component equality: projective_rescaling_witness expresses equality after one explicit nonzero common complex scale;
• there is deliberately no ordinary Eq, vector addition, or multiplication for projective points;
• affine_to_projective implements (z1,...,zn) -> [1:z1:...:zn];
• projective_first_chart is partial, and [0:1] in CP^1 stays outside the finite chart.

The complex carrier is deliberately parametric. The current canonical line does not yet have a settled general real-scalar/precision hierarchy that can honestly define the numerical field C without colliding with separate Float16/Float32 work. This PR therefore does not define Complex as two Doubles, two Float32 values, SIMD lanes, or shader vectors. The x86-64 leading implementation supplies the first concrete Float32 executable arithmetic against the shared corpus.

Shared corpus

_/fixtures/complex-projective/float32.json is the backend-neutral Float32 corpus for exact arithmetic, floating division/reciprocal, bounded complex exponential, polynomial/rational evaluation, polar observation, projective rescaling by real and phase factors, non-equivalence, affine charting, CP^1 infinity, and the deterministic R(z) exp(q(z)) headless render scene.

The bounded exponential fixture derives its analytic truncation term from exp(|q|)|q|^8/8!; inputs outside the declared radius are to fail closed rather than gain an arbitrary tolerance.

Acceptance

edric009 typechecks, builds, and executes ComplexProjectiveTests.idric. The exact ExactComplex value from QuadraticForms is used only so the structural quotient identities reduce exactly at compile time.

Exact head 8f86736f752acaafbbf529af89a5c9ae90cf6e0b has green PR merge-topology compiler and source-layout workflows. The separate duplicate push-only compiler failure is the documented unrelated edric010 / PREFIX_CHANGED harness issue and is not promoted into a complex/projective failure.

Idriç #80 is merged. This PR is retargeted to the canonical Idriç branch and does not touch the adjacent holomorphic-contract documentation PR #79.

[isomorphisms]

Follow-on exact-head acceptance for 8f86736f752acaafbbf529af89a5c9ae90cf6e0b:

• Reproduced the original ComplexProjective.idric undefined-name failure.
• Applied the narrow structural repair in this head: explicit carrier/rank binders plus the exports required for cross-module definitional reduction. No mathematical equation, scalar representation, precision rule, or backend boundary changed.
• Local exact-branch compiler bootstrap and ./edric test --only idris2/basic/edric009: PASS (1/1).
• PR merge-topology build: PASS: https://github.com/isomorphisms/Idric/actions/runs/34685742117
• Source-layout checks: PASS: https://github.com/isomorphisms/Idric/actions/runs/34685742101

A duplicate push-only run passed edric009 and then failed in unrelated edric010 because that older branch topology's test harness reads unset PREFIX_CHANGED: https://github.com/isomorphisms/Idric/actions/runs/34685740094. I have kept that as a separate fail-closed receipt rather than calling it a complex/projective failure or broadening this PR into test-harness repair.