Design: Settings Definition API & Conventions

### Why
Define clear settings definition structure, scoping & naming conventions, for storing user/state in Elsa Studio. Make it easy to add, validate, and version settings at any layer. Include best-practices for Blazor (and MudBlazor), key naming, model versioning, and approach to future server-profile extensions.

### Acceptance Criteria
- Document:
- Setting definition API (C# record/class structure example)
- Supported persistence modes (local, session)
- Storage key naming conventions (see epic)
- Versioning and migration approach
- Validation patterns
- Document future extensibility to add Profile (server) mode
- Example: definition for `theme`, `shell geometry`, `shell session toggles`, `table view state`
- Scoping per screen/component
- Where to locate defaults

### Deliverables
- ADR in /docs or /src/framework/Core/Documentation/
- Example C# setting record(s)
- Diagram if possible

Start by reviewing the requested ADR locations in /docs and /src/framework/Core/Documentation/, then map the acceptance criteria for the Settings Definition API, persistence modes, naming, versioning, validation, and scoping. Done means an ADR with the requested C# examples, settings examples, future Profile-mode extension, defaults guidance, and a diagram if possible.

Written by the indexing model from the issue text.