Clarify whether validator methods are directly callable

[eboody]

Summary

#[validators] rewrites validator methods into generated impls that take hidden machine-field parameters. That makes the methods usable from Statum's rebuild path, but it does not preserve direct calls like row.is_draft().

This behavior predates the non-authoritative scanning refactor, but the refactor is a good point to decide whether that surface is intentional.

Current behavior

A source method like:

fn is_draft(&self) -> statum::Result<()> {
    Ok(())
}

is re-emitted with hidden machine-field parameters during validator expansion.

Relevant code:

• statum-macros/src/validators.rs
• statum-macros/src/validators/emission.rs

Decision needed

Pick one of these and enforce it clearly:

1. Validator methods are part of the user-callable API.

   • Preserve the original callable signature.
   • Keep machine-field injection internal to rebuild helpers.
   • Add tests that direct calls still compile.

2. Validator methods are internal implementation detail for typed reconstruction.

   • Document that direct calls are not part of the supported surface.
   • Hide or reshape the generated methods so the surface is less misleading.

Why this matters

Right now the source code suggests validator methods are ordinary inherent methods, but the expanded callable shape differs. That is an avoidable ergonomics trap.

Suggested acceptance

• documented intended behavior
• tests for the chosen behavior
• no ambiguity about whether row.is_state() is supported