[FRONTEND] Low-precision float support: resolve_dot capability contract, fp8 cast routing, interpreter float conversion rewrite

[zeroherolin]

Summary

Common-layer groundwork for per-backend low-precision float (fp8/fp4) support. The backend PRs (PPU, MThreads, and so on) build on this branch.

• backends/compiler.py: adds DotCap / DotSupport — the answer type for two new optional codegen-function queries, resolve_dot(a_dtype, b_dtype, acc_dtype, M, N, K) and resolve_dot_scaled(lhs_format, rhs_format). A backend that registers them owns its dot legality rules; the semantic layer raises on UNSUPPORTED (with the backend's diagnostic) and emits a compile-time warning on EMULATED, so non-native paths cannot degrade silently.
• language/semantic.py: queries resolve_dot(_scaled) after the legacy e4b15/fnuz upcasts so rules see effective dtypes; adds fp8 cast routing via supported_fp8_cast_dtypes (numeric-cast whitelist) and custom_cast_fp8_dtypes (dtypes lowered through convert_custom_types).
• runtime/interpreter.py: rewrites _convert_float as exact decode/encode through fp64 with strict RTNE/RTZ and correct fn/fnuz/none special-value conventions. The previous implementation rounded half-up (not round-to-nearest-even) and mishandled inf/NaN of the non-IEEE fp8 formats.
• python/tutorials/precision/: runnable fp8 (E4M3FN) and fp4 (E2M1) walkthroughs driven by the declared capabilities; they degrade gracefully on backends that do not declare them.

Backward compatibility

Every existing backend is unaffected:

• resolve_dot / resolve_dot_scaled are looked up with codegen_fns.get(...); absent means the legacy dtype whitelist path runs unchanged.
• custom_cast_fp8_dtypes defaults to ("fp8e4b15",), preserving the legacy fp8e4b15-only convert_custom_types routing; supported_fp8_cast_dtypes is only enforced when a backend's options define it.

Behavior changes to be aware of

• Interpreter-mode numerics change for all backends: downcasts now use strict RTNE instead of round-half-up, and fp8 special values follow each format's convention (e4nv NaN = 0x7F/0xFF, fnuz NaN = sign-only pattern, e4b15 has neither inf nor NaN). fnuz results that round to zero encode as +0, never the sign-only NaN code. This is a correctness fix; results move closer to hardware.
• Verified: for all four fp8 formats, all 256 encodings decode/encode roundtrip bit-exactly, and negative underflow encodes to 0x00 (previously 0x80 = NaN for fnuz formats).

Bug fixes included

• runtime/interpreter.py: create_load / create_masked_load were missing the flagtree_hints parameter that the semantic layer passes since the hints feature landed — interpreter mode currently fails on any load.
• backends/__init__.py: dunder probes (inspect, copy, ...) on the lazy tl.ext proxy now raise AttributeError as the protocol expects, instead of failing backend-module resolution.

[zeroherolin]

goto #1116