#[rite] should infer tier from function name suffix

Nobody has claimed this yet.

## 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.

```rust
// 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.

Start in src/ by locating the #[rite] macro implementation, the generated macro registry, and the existing incant! suffix handling. Trace the no-argument token-parameter path and inspect how unknown tiers and target features are reported. Done means suffix inference works, disagreement produces a compile error, and existing explicit and token-parameter forms remain unchanged.

Written by the indexing model from the issue text.