feat(shard): express swizzled composed layouts as CuTe does

[zhen8838]

Why

• Layout and ComposedLayout could only state an affine coord-to-offset mapping, so the XOR swizzle a WGMMA shared-memory operand needs (issue feat(shard): let a layout carry a non-affine transform #173) had nowhere to live.

What

• Swizzle(bits, base, shift) ports CuTe's Swizzle<B,M,S> as a frozen functor that ComposedLayout.inner may carry. It is not a LayoutBase: its domain comes from the composition's outer.
• layout_algebra gains CuTe's swizzle specializations: apply, cosize, coalesce, the involution inverses, and composition — including composition(Layout, Swizzle), which rebuilds the swizzle over the bits the layout leaves active so the answer is again a swizzle-inner composed layout rather than a Swizzle in outer.
• CUDA codegen renders the composition unchanged, cute::make_composed_layout(cute::Swizzle<B,M,S>{}, cute::Int<offset>{}, ...), for both the layout type and the layout value.
• The device runtime reads steps off the affine part of a shard layout (CuTe deletes stride() on a ComposedLayout) and projects a composed one by folding the instance's origin into the composition's offset instead of advancing the engine pointer.
• One new test carries a (128, 4) f32 tile through swizzled SMEM: print/parse round-trip, codegen, nvcc, and the device, plus the emitted-layout assertion that running the kernel cannot make.

Contract

• ComposedLayout.inner widens to LayoutBase | Swizzle | None; outer, ShardLayout.layout and TensorType.layout are unchanged, so a bare Swizzle is still not a tensor layout. docs/spec/shard.md §4 and the new §4.1 state it.
• The device projection rule for a composed shard layout is new public behavior: docs/spec/runtime.md §2.4.1 states that the origin reaches the composition's offset and not the engine pointer, and that a composed layout does not take the whole-tensor shortcut.
• A Swizzle states where an element lives, never which element a logical coordinate names: shape, domain_rank, the axis numbering a Split references and the access relation an op states are read off outer and are the unswizzled ones. docs/spec/shard.md §4.1 states it.
• A swizzled layout is still refused as a mesh execution scope, unchanged.

Risk

• Transpose, Reshape and Slice carry the swizzle, since all three only relabel the domain and a window's start is a constant shift of the index that offset already holds. A register engine refuses it by name, as do a composed inner that is not a Swizzle and a Swizzle over a ShardLayout outer, which the shard slice path would drop.
• composition(Layout, Swizzle) and the inverses reject a non-zero composition offset: CuTe's rule for that case puts a Swizzle on the domain side, which this IR cannot represent.
• The ported composition and swizzled inverses have no caller in src/ yet, so nothing exercises them; this PR ships them because the issue asks for CuTe's algebra, not because a code path needs them today.
• No WGMMA instruction and no performance gate ship here; this is the layout the operand needs, not the instruction that consumes it.