docs: make performance methodology explicit

[Lythaeon]

Description

Cleans up how SOF explains performance and optimization in the public docs.

The previous docs had two problems:

• the performance story was repeated too many times across the root README, the sof crate README, and multiple GitBook pages
• the wording was still too generic and too 0.13.0-only, even though SOF performance work is a multi-release story with concrete measured examples

This PR fixes that by making one GitBook page the canonical performance page and trimming the rest of the docs down to short references.

Changes

Detailed list of what changed:

• Added a dedicated GitBook page for the full performance story:
  • docs/gitbook/architecture/performance-and-measurement.md
• Moved the detailed methodology and measured examples into that one page:
  • hypothesis -> baseline -> one change -> A/B -> perf -> metrics -> keep only validated wins
  • explicit multi-release lineage instead of pretending optimization started in 0.13.0
• Updated the root README.md to keep only a short, product-facing summary plus a link to the canonical GitBook page.
• Updated crates/sof-observer/README.md to keep only the runtime-facing summary instead of repeating the same long performance story again.
• Trimmed GitBook pages that were repeating the same material so they now just reference the canonical page:
  • docs/gitbook/use-sof/why-sof-exists.md
  • docs/gitbook/architecture/system-overview.md
  • docs/gitbook/architecture/README.md
  • docs/gitbook/operations/tuning-and-env.md
• Added the new page to docs/gitbook/SUMMARY.md.

Representative concrete examples now documented in one place include:

• 0.12.0 VPS tx visibility improvement:
  • 59.978 / 8.007 / 6.415 ms -> 44.929 / 6.593 / 5.370 ms
  • first_shred / last_required_shred / ready -> plugin
• 0.12.x derived-state dispatch slice:
  • 12424.649 ns/iter -> 8603.920 ns/iter
• 0.13.0 provider tx-kind classification:
  • 34112us -> 4487us
  • about 7.6x faster
• 0.13.0 provider dispatch path:
  • 39157us -> 5751us
  • about 6.8x faster
• 0.13.0 provider serialized-ignore path:
  • 42422us -> 23760us
• 0.13.0 websocket parse path:
  • 162560us -> 133309us

Any architecture/runtime/infra implications:

• No runtime behavior changes.
• No API changes.
• Docs-only restructuring and clarification.

Motivation

Business motivation:

• SOF should sound like what it is: a measured, iteratively optimized runtime, not a project repeating generic claims about being fast.
• Readers should be able to find the real performance story in one place instead of reading the same paragraph in several places.

Technical motivation:

• The repository already has concrete performance history across releases, PRs, fixture A/B results, and perf validation.
• The docs should reflect that history accurately, without duplication and without over-scoping the claim.

Alternative approaches considered:

• Keep spreading the same perf wording across several pages.
• Rejected because that created duplication and still did not explain the full measured lineage cleanly.

Scope and impact

• Affected slices: docs only
• Data/API changes: none
• Backward compatibility: unchanged
• Performance impact: none
• Security impact: none

Testing

• Unit tests
• Integration tests
• Manual verification
• Performance checks (if applicable)
• Security checks (if applicable)

Commands/results:

git diff --check

Result:

• passed

Related issues and documentation

• Fixes:
• Related:
• Architecture docs:
  • docs/gitbook/architecture/performance-and-measurement.md
  • docs/gitbook/architecture/system-overview.md
  • docs/gitbook/architecture/README.md
• Operations/runbook updates:
  • docs/gitbook/operations/tuning-and-env.md
• Product positioning docs:
  • docs/gitbook/use-sof/why-sof-exists.md
  • README.md
  • crates/sof-observer/README.md

Reviewer checklist

• Code follows project standards and architecture constraints
• Slice boundaries are respected (docs/architecture/ard/0003-slice-dependency-contracts.md)
• Tests added/updated and passing
• Documentation updated (README/docs/operations as needed)
• No undocumented breaking change
• Performance trade-offs documented where relevant
• Security considerations addressed where relevant

Additional notes

This PR does not add a new performance claim. It restructures the docs so the performance claim is:

• explicit about methodology
• explicit about scope
• grounded in concrete measured examples
• documented once in the GitBook instead of repeated across several pages