Refactor Rust versioned API modules by feature

[pgherveou]

Context

The Rust truapi crate currently splits one logical API feature across three top-level module trees:

rust/crates/truapi/src/v01/foo.rs
rust/crates/truapi/src/v02/foo.rs
rust/crates/truapi/src/versioned/foo.rs

That makes versioning explicit, but it also means a change to one feature requires jumping across separate version roots. As more APIs grow v2+ payloads, this can make the feature boundary harder to read than the version boundary.

Proposal

Explore reorganizing the code so each API feature owns its payload versions and versioned envelope next to each other:

rust/crates/truapi/src/foo.rs      # feature module + versioned envelope wiring
rust/crates/truapi/src/foo/v01.rs  # v1 payloads
rust/crates/truapi/src/foo/v02.rs  # v2 payloads, when present

For example, account.rs would define or re-export the versioned HostAccount* envelope types while account/v01.rs and account/v02.rs hold the concrete SCALE payloads for each protocol version.

Why

• Keep all types for one logical API surface in one local module tree.
• Make v2 additions easier to review because the old payload, new payload, and versioned wrapper are adjacent.
• Reduce duplication in top-level v01.rs, v02.rs, and versioned.rs module registries.
• Make docs and imports feature-oriented rather than version-root-oriented.