Generate typed invoke() command bindings with tauri-specta

[Zlyzart]

Summary

Follow-up to #83 (which generates the DTO types via specta). Once the type bindings are in place, replace the hand-written invoke() calls in ui/src/api/tauri.ts with typed command wrappers generated by tauri-specta. Today invoke("get_board") is typed only by its return annotation — the command name string and argument names are unverified. tauri-specta can emit a commands.ts that generates a strongly-typed wrapper per #[tauri::command], making a renamed command a compile error in TypeScript.

Depends on

#83 — specta derives and tauri-specta dep must be in place first.

Needs scoping first

• Exact tauri-specta API for typed command export (tauri_specta::collect_commands! or equivalent in v2).
• Whether to emit commands.ts as a separate file or fold it into the bindings file from Generate the Rust↔TypeScript type contract with specta/tauri-specta #83.
• Migration: replace the four invoke() calls in ui/src/api/tauri.ts with the generated wrappers.
• CI staleness check scope — extend the check from Generate the Rust↔TypeScript type contract with specta/tauri-specta #83 or add a separate step.

[github-actions]

Needs decisions before this can be refined

This issue depends on #83 (which is not yet implemented — no specta deps, no bindings.ts, no derives in main.rs). Even setting that aside, it lists explicit open design questions that need human answers before scope can be locked down.

Concrete decisions required:

1. File layout. Should the generated command wrappers land in a separate commands.ts, or be emitted into the same bindings file that Generate the Rust↔TypeScript type contract with specta/tauri-specta #83 produces? The choice affects how consumers import and how CI is structured.

2. CI check scope. Should the staleness check for commands.ts extend Generate the Rust↔TypeScript type contract with specta/tauri-specta #83's existing CI step (one regenerate-and-diff step for both types and commands), or be a separate step? The answer determines what the ci-complete.yml diff looks like.

3. Blocked on Generate the Rust↔TypeScript type contract with specta/tauri-specta #83. Should this issue be formally marked status:blocked until Generate the Rust↔TypeScript type contract with specta/tauri-specta #83 is complete, or is it expected to be implemented in the same PR?

Once those three questions are answered, this issue can be fully refined with an unambiguous acceptance checklist.