#[rite] should infer tier from function name suffix

[lilith]

Summary

#[rite] currently requires the tier as a macro argument (#[rite(v3)]) or infers it from a token parameter type (fn dot(_: X64V3Token, ...)). Since incant! already requires functions to be suffixed with the tier name (dot_v3, dot_v4, dot_neon), the suffix is always present — but the macro doesn't read it.

Add a third mode: when #[rite] has no arguments and no token parameter, infer the tier from the function name's last _-separated suffix by looking it up in the registry.

// Today — tier repeated in two places:
#[rite(v3)]
fn dot_v3(a: &[f32; 8], b: &[f32; 8]) -> f32 { /* avx2 body */ }

// Proposed — suffix is the single source of truth:
#[rite]
fn dot_v3(a: &[f32; 8], b: &[f32; 8]) -> f32 { /* avx2 body */ }

Both expand to the same output: #[target_feature(enable = "avx2,fma,...")] + #[inline] + #[cfg(target_arch = "x86_64")].

Why

1. Eliminates duplication. The suffix _v3 is already mandatory for incant! dispatch. Requiring #[rite(v3)] on top of that is stating the same information twice. If the suffix and the macro arg ever disagree, that's a silent bug.

2. Matches the mental model. The docs already teach "name your function process_v3." The macro should reward that convention, not ignore it.

3. Drops the token parameter for helpers. #[rite] fn dot(_: X64V3Token, a, b) wastes a parameter slot on a zero-sized proof that nothing in the body reads. The suffix carries the same information without the syntactic weight.

4. Searchable. grep -rn '_v3' src/ finds all AVX2 code regardless of whether they used #[rite(v3)], #[rite] with a token, or #[rite] with suffix inference. One convention to remember.

Behavior

• #[rite] with no args and no token parameter: split function name at last _, look up suffix in the generated macro registry. Error if suffix is unknown, listing known suffixes.
• #[rite] with no args and a token parameter: existing behavior (infer from token type). No change.
• #[rite(v3)] with explicit tier: existing behavior. No change.
• If both a suffix and explicit arg are present and disagree, emit a compile error.

Scope

This is additive — no deprecation, no breaking change. Existing #[rite(v3)] and token-param forms continue to work. Suffix inference is a third input path to the same code generation.

The same suffix-inference logic could later be added to #[arcane] for consistency, but that's a separate decision since #[arcane] has the wrapper/sibling expansion that #[rite] doesn't.