Emit tensor_encoding comments in StableHLO output (#473)

[michalharakal]

Closes #473.

Summary

First step after #469: teach the StableHLO emitter to read `TensorSpec.tensorEncoding` and preserve it through the compile boundary. Today, even though `TraceToGraphBuilder.finalize` carries `TensorEncoding.Q8_0` / `Q4_K` / `TernaryPacked` / `TurboQuant` onto weight-node output specs, `StableHloConverter` ignores the metadata and emits MLIR that looks identical to a dense FP32 graph. This PR is the cheapest reversible hook that fixes that.

Two commits:

1. Failing test

`EncodingAnnotationTest` with two cases:

• Positive: build a graph whose weight input `TensorSpec` is annotated with `TensorEncoding.Q8_0` via `withTensorEncoding` (matching what `TraceToGraphBuilder.finalize` produces after Plumb TensorEncoding into TensorSpec.metadata (P0-1 step 1) #469), run it through `StableHloConverter`, assert the emitted module text contains a `tensor_encoding` comment naming `encoding=Q8_0` and `name=w`. Red against `main`.
• Negative: a dense FP32 graph with no encoding metadata must emit no `tensor_encoding` annotation. A `null` `tensorEncoding` is the unknown / not-carried state, intentionally distinct from `TensorEncoding.Dense`, and the emitter has to treat it as silent. Green baseline.

2. The fix

• `ConversionContext.emitEncodingAnnotation(role, index, spec)` — helper that emits a single `tensor_encoding` MLIR comment when `spec.tensorEncoding` is non-null. No-op otherwise.
• `StableHloConverter.initializeInputValues` annotates each function-argument input with `role="input"`.
• `StableHloConverter.processNode` annotates each non-input node's output specs with `role="result"` immediately before the converter is invoked, so the annotation precedes the op that produces the encoded value.

Net effect: a Q8_0 weight node flowing through the emitter now produces a line like

```mlir
// tensor_encoding: role=result index=0 name=w encoding=Q8_0
```

right before the op that materializes `%w`. MLIR tools ignore comments but text round-trips preserve them, so IREE and any downstream consumer can read the encoding from the emitted `.mlir` file. Converters that want finer-grained placement can call the helper themselves.

Why comments, not real quant dialect ops

StableHLO's `quant.` dialect uses typed quant element types (`!quant.uniform<i8:f32, 0.1:128>`) that are fiddly to emit as text and are not yet consumed anywhere in the SKaiNET pipeline. Emitting them prematurely would just produce MLIR that no existing tool in this repo validates. Comments are the cheapest reversible first hop. Follow-up PRs in the P0-1 track can either grow the comment into a structured `#skainet.tensor_encoding` attribute or cut over to real `stablehlo.custom_call @dequantize_q8_0` stubs matching the style already used by `ReductionOperationsConverter`.

Test plan

• `EncodingAnnotationTest` — both cases green
• Full `:skainet-compile:skainet-compile-hlo:jvmTest` — green (no regressions from the new comment)
• CI: full multiplatform build

Out of scope

• Real `stablehlo.uniform_quantize` / quant dialect emission.
• Teaching IREE or any downstream tool to actually consume the comments. That's downstream work.
• Changing the shape of `TensorEncoding` or `TensorSpec`.
• Softmax / conv / attention lowering (Fix softmax StableHLO lowering to use real reductions #467 is separate).

🤖 Generated with Claude Code