TT-Forge (Tenstorrent's MLIR-based compiler; the TT-Bridge / graph-frontend layer)

Added as the graph-compiler layer of the Tenstorrent stack that engines/niche-tt-metal covers from the kernel side, because a deployment planner choosing Tenstorrent needs both: TT-Forge to get a model down, TT-Metalium to write what it misses. The vendor's stack overview is unusually explicit about the boundaries - TT-Forge 'bridges high-level machine learning frameworks with the Tenstorrent software stack', TT-NN is the pre-packaged operator library, TT-Metalium is the low-level programming model - which is what makes the split record-able. The task framed this as 'TT-Bridge and TT-Metal'. TT-Metalium is already covered by engines/niche-tt-metal, so this record covers the compiler. On the 'TT-Bridge' name: the GitHub API has no tenstorrent/tt-bridge repository (404) and PyPI has no tt-bridge package (404), while tenstorrent/tt-forge exists, is described by its own repo as 'Tenstorrent's MLIR Based Compiler', and is the live project - so I recorded what exists rather than the name as given. It is plausible TT-Bridge is/was an internal or renamed frontend; the repo's own history would settle it, and I did not find a primary source either way, so no claim is made about the naming. output_artifacts carries amdgcn as a deliberate approximation and target_backends is empty: neither is accurate. TT-Forge emits TT-Metalium device binaries, and the schema's enums (built for CUDA/ROCm/Metal-class hardware) have no term for it. Both fields are recorded as-is rather than dropped, because leaving them empty loses the information that a real artifact is emitted somewhere - but a reader must not take amdgcn literally here. autotuning is false: nothing in the vendor's stack documentation describes a tactic search or config search in TT-Forge. If Tenstorrent adds one, this field is the thing to revisit.