feat(unroll): point not-unrolled warnings at the #[unroll] attribute

[midagedev]

Summary

I hit this while working on bloomery, an LLM inference engine with 67 #[unroll] sites. A const-generic prefill kernel printed "the loop was not unrolled" with no position. hhdri reported the same on #1346: finding three such loops in one kernel meant converting them one at a time. This adds the #[unroll] attribute's position to each warning.

warning: #[unroll] requested but the loop was not unrolled: full #[unroll] needs a compile-time-constant trip count; ...
  --> src/main.rs:103:13

Changes

• cuda-macros: the __unroll_config marker takes the #[unroll] attribute's span, not the #[kernel] span. The const-eval error for a bad factor now points at the attribute too (policy_config_invalid_unroll.stderr).
• mir-transforms: each not-unrolled warning adds --> file:line:col from the hint op. The first line is unchanged. With no position, nothing is added. One helper now unlinks a loop's hints and returns the position.
• With debug info, the goto that replaces the marker also takes the #[unroll] line.

Testing

On Linux (RTX 3090 / A6000), the just check steps run by hand:

• fmt-check, clippy (both scopes), test, test-cuda and cargo doc pass, rebased on e84e5b3d (Pliron 0.19.0).
• cargo oxide run unroll_smoke: PASS. Its PTX is byte-identical to main.
• The new span test fails with main's launch_attrs.rs ((1, 0) instead of (2, 4)). The warning test fails on a variant that drops the column.

I used Claude Code and a GLM agent to write this patch. I reviewed and ran it.

Checklist

• All commits signed off (git commit -s)
• SPDX headers on new source files (no new files)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.