docs: add quantum contributor documentation

[Kryptos-FR]

PR Details

Add in-repo technical documentation covering Stride's Quantum graph framework for engine contributors and maintainers.

Four new files under docs/quantum/:

• README.md — entry point: five-layer architecture diagram, end-to-end data-flow walkthrough, decision tree for when Quantum code is actually needed, and a spoke-file map
• graph-model.md — core Stride.Core.Quantum layer: IGraphNode/IObjectNode/IMemberNode types, NodeContainer, mutation API, change listeners, and listener lifetime rules
• asset-graph.md — Stride.Core.Assets.Quantum layer: AssetPropertyGraph, override model (inherited / overridden / new), AssetPropertyGraphDefinition for content-reference declaration, AssetQuantumRegistry registration
• property-grid.md — presenter layer: INodePresenter/IAssetNodePresenter key members, INodePresenterUpdater pipeline, full cookbook (hide a node, rename, add numeric constraints, make read-only, reorder, attach commands, add virtual nodes)

Cross-references to docs/asset-system/ are included where the two systems meet (e.g. the Tier 1 / Tier 2 editor decision in the asset-system docs maps directly to the Quantum decision tree here).

Note: Anthropic's Claude contributed to writing the doc.

Motivation

Quantum is one of the most opaque parts of the Stride editor codebase. Contributors working on new asset types or custom property grid behaviour (such as in #3103) frequently need to interact with it without any written guide. This documentation maps the five-layer stack, explains the override model, and provides a concrete INodePresenterUpdater cookbook so contributors can get productive without reverse-engineering the existing code.

Keeping it in-repo (following the precedent set in #3121) means it stays versioned alongside the code, is immediately discoverable when browsing the source, and is available to AI agents without any extra context setup.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have built and run the editor to try this change out.