Introduce T term syntax mapping to ⊥ in XMIR

[maxonfjvipon]

The fragile-objects epic #5261 needs a bottom term, T, analogous to ⊥ in 𝜑-calculus. This adds it to the spec-driven parser as a self-contained leaf: the source token T becomes <o base="⊥"/>, and the printer turns it back into T.

The mapping follows the existing §9.3 table (Q→Φ, $→ξ, ^→ρ, void→∅), so T slots in as one more reserved single-character token. It collides with nothing — NAME is lowercase-led and Q is the only other uppercase glyph.

The subtle part is keeping ⊥ opaque through the XSL pipeline. Two passes would otherwise mangle a bare ⊥: add-default-package prefixed it to Φ.⊥, and build-fqns tried to resolve it as a name. Both now exclude it, through a new special in _specials.xsl:

<xsl:variable name="eo:bottom" select="'⊥'"/>

Scope is syntax only. The runtime meaning of ⊥, the ?. operator, and the rest of #5261 are separate tickets. Tests cover the parse (T → ⊥ surviving the full sheet chain), the print round-trip, and the new Value.Kind.TERM.

Closes #5264.

[github-actions]

🚀 Performance Analysis

All benchmarks are within the acceptable range. No critical degradation detected (threshold is 100%). Please refer to the detailed report for more information.

Click to see the detailed report

Test	Base Score	PR Score	Change	% Change	Unit	Mode
benchmarks.XmirBench.xmirToEO	13614.241	13690.366	76.124	0.56%	ms/op	Average Time

⚠️ Performance loss: benchmarks.XmirBench.xmirToEO is slower by 76.124 ms/op (0.56%)

[maxonfjvipon]

@yegor256 please check

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[0crat]

@maxonfjvipon Thanks for the contribution! You've earned +12 points for this: +16 as a basis; -4 for too many hits-of-code (259 >= 100). Please, keep them coming. Your running score is +378; don't forget to check your Zerocracy account too).