feat(ui): Implement distinction for Core vs. Research fields

[rsthornton]

Description:

This pull request introduces an exploratory UI/UX pattern to visually distinguish between Core (stable, essential) and Research (experimental, subject to change) fields in the details panel.

The primary goal is to manage user expectations by clearly communicating which parts of the system model are foundational and which are still under active development. This is a first pass at a design solution, and I am actively seeking feedback on the approach.

Proposed Solution

This implementation uses a global toggle to show or hide all "Research" fields across the application.

• Global Toggle: A new ResearchFieldToggle component is provided at the top of the details panel, allowing users to opt-in to seeing experimental fields.
• Context Provider: A ResearchFieldProvider uses a Leptos context to manage the global show/hide state, making it accessible to all child components.
• Wrapper Components:
  • <ResearchField>: Wraps any experimental input field. It applies a distinct visual treatment (a dashed amber border and a "Research Field" label with a tooltip) and respects the global toggle's visibility state.
  • <CoreField>: A simple wrapper for stable fields, providing a consistent structure for future styling.
• Help System: The FieldHelp data structure has also been updated to categorize help text as either Core or Research, laying the groundwork for more context-aware documentation.

Request for Design Feedback

This solution is a functional prototype, but I'm not convinced it's the perfect final design. I would greatly appreciate feedback on the following points:

1. Visual Design: Is the dashed amber border and "Research Field" label an effective and clear way to distinguish these fields? Are there better visual cues we could use?
2. Terminology: Is "Research Field" the most intuitive term for our users? Should we consider alternatives like "Experimental," "Advanced," or "Beta" instead?
3. Interaction Model: Is a single, global toggle the best approach? Or would it be better to have a more granular control, perhaps on a per-section basis?
4. Discoverability: How can we best introduce this concept to users? Is the current toggle and its tooltip sufficient?

This implementation is a starting point, and I'm very open to rethinking the design based on feedback.