Aligned Move, Rust and TypeScript documentation for Audit Trail and Notarization

[chrisgitiota]

Summary

Aligns the documentation across the three implementation layers — Move smart contracts, Rust client crates, and WASM/TypeScript bindings — for both Audit Trail and Notarization.

The goals are

• users can live with the docs in the language they use - no need to traverse from TS do Rust or Move
• every public Move entity, its Rust counterpart, and its WASM/TS counterpart describe the same behaviour with the same vocabulary, so a reader can move between layers without re-deriving the contract semantics.

No behavioural changes — documentation, style guides, and tooling only.

See DOC-SKILL-EXAMPLES for examples and explanations how to use the SKILL based doc alignment process.

What's in the PR

Style guides (new, top-level)

• MOVE-DOC-STYLEGUIDE.md — authoritative rules for Move doc comments (audience, block ordering, capability gating, abort/event conventions).
• bindings/wasm/DOC-STYLEGUIDE.md — equivalent rules for wasm-bindgen-generated TSDoc/JSDoc (TS-visible names, {@link} syntax, allowed tags, etc.).
• No Rust style guide ATM - Audit Trail and Notarization follow different styles. Discussion needed which path to follow.

Per-product CLAUDE.md guides

• audit-trail-move/CLAUDE.md, notarization-move/CLAUDE.md — reference the Move styleguide and pin product-specific terminology (e.g. the "Notarization Methods" rules).
• bindings/wasm/audit_trail_wasm/CLAUDE.md, bindings/wasm/notarization_wasm/CLAUDE.md — same for the TS side.

API mapping files (new)

• audit-trail-move/api_mapping.toml, notarization-move/api_mapping.toml — map every public Move function/struct/enum to its Rust and WASM/TS counterparts. Used as index when syncing docs across layers to reduce token consumption resp. compare docs of the specific languages more efficiently.

Product-agnostic skills (new, under .claude/skills/)

• init-api-mapping — bootstraps an api_mapping.toml for a new product.
• update-api-mapping — reconciles the mapping against a git revision (added/removed entities).
• sync-product-docs — syncs Move/Rust/WASM doc comments using the mapping.

Doc comment rewrites

• audit-trail-move/sources/*.move, notarization-move/sources/*.move — full rewrite under the new style guide, including consistent abort and event sections.
• audit-trail-rs/src/**, notarization-rs/src/** — Rust docs updated to mirror the Move semantics (per-method bullet lists where behaviour differs, accurate lock semantics, TimeLock::Infinite destruction rule, etc.).
• bindings/wasm/audit_trail_wasm/src/**, bindings/wasm/notarization_wasm/src/** — TSDoc rewritten to TS-visible names with {@link} references, matching the Move/Rust semantics from the mapping.

Notable conventions established

• Notarization Methods: Dynamic / Locked are always referred to as Notarization Methods (never "variant", "kind", "mode", etc.); per-method behaviour is documented as a fixed-order bullet list so future methods can be added without restructuring prose.
• Audit Trail capability gating: every gated entry point ends with a Requires the {@link Permission.X} block.
• Move events: emissions are now mirrored on the Rust and WASM/TS layers ("Emits a Foo event on success.").

Test plan

• cargo build --workspace --tests --examples
• cargo clippy --all-targets --all-features
• cargo doc --workspace --no-deps produces no rustdoc warnings
• cd bindings/wasm/notarization_wasm && cargo check --target wasm32-unknown-unknown
• cd bindings/wasm/audit_trail_wasm && cargo check --target wasm32-unknown-unknown
• npm run build in both WASM crates; skim generated .d.ts for broken {@link} references or stray rustdoc artifacts
• Spot-check Move docs render correctly (no # Errors / # Examples rustdoc headings leaked into Move sources)