Reduce repeated setup code across tutorials with shared helpers and clearer structure

## Problem

Pioneer feedback reports that tutorials are fragmented and repetitive. In particular, long setup snippets and utility functions are repeated across many tutorial listings, making the examples harder to scan and harder to adapt.

Examples called out:

- client initialization code repeated in many `main` functions,
- helper functions such as `create_library` and `wait_for_tx` repeated across tutorials,
- creating a new repo/app per tutorial instead of giving developers a coherent progression,
- tutorial pages mixing the concept being taught with a large amount of boilerplate.

Some related issues already cover pieces of this, but there is no single issue focused on reducing repeated tutorial boilerplate and improving the tutorial structure for readability.

## Why this matters

Tutorials are often a developer's first working mental model. If every page repeats large setup blocks, the important protocol/client concept gets buried. This is especially harmful for advanced topics like MASM, FPI, network notes, and custom account flows where readers need to focus on the new logic.

## Proposed scope

Refactor tutorial structure so repeated setup is shared, collapsed, or linked instead of duplicated inline.

Potential improvements:

- create shared helper modules/files for common Rust client tutorial setup,
- use a consistent "setup once, focus on the new code" structure,
- move repeated helpers like `create_library` and `wait_for_tx` into shared snippets or imports,
- make boilerplate collapsible where full listings are still useful,
- align web tutorials around a single app/project progression where practical,
- keep complete runnable source available while making docs pages easier to read.

## Acceptance criteria

- Repeated tutorial setup code is reduced or moved into shared helper files/snippets.
- Tutorial pages distinguish required boilerplate from the concept-specific code being taught.
- Full runnable source remains available for each tutorial.
- Existing related tutorial cleanup issues are linked or folded into the work plan.
- Advanced tutorials such as FPI/network-note flows are easier to scan because reusable setup is not repeated inline.

## Related context

- Pioneer feedback from Zoro via Domi.
- 0xMiden/tutorials#107
- 0xMiden/tutorials#115
- 0xMiden/tutorials#63
- 0xMiden/tutorials#122

Examine the tutorial files in the repository to identify repeated setup code like client initialization and helper functions (create_library, wait_for_tx). Look for existing shared modules or snippets. The goal is to refactor these into shared helpers, ensuring each tutorial page remains runnable. Check related issues (#107, #115, #63, #122) for context. 'Done' means reduced boilerplate in tutorials and a clearer separation between setup and concept-specific code.

Vom Indexierungsmodell aus dem Issue-Text verfasst.