Compat baseline 1/5: document upstream-vs-fork requirements and pin exact commits in a compatibility matrix #131

Part of #102. First and independent: docs only, no code.

#102 lists the source-level dependency boundaries (commits 0dcc913, d876ded, 05be9eb, 03e1c1d, f7c761c, 7633211, e5339c0) and which plugins need each. Turn that list into a maintained compatibility matrix.

Scope

• Add a compatibility matrix document (e.g. docs/compatibility.md) with one row per host API/commit: what it provides, which plugin(s) and feature(s) require it, whether it is required or optional for that plugin, and whether it lives upstream or only in this fork.
• Pin the exact commits (not version strings, which are reused; the current checkout reports 0.3.0-alpha.2 across many commits) until a release identifies the baseline.
• Record the host and plugin revisions each row was verified against, and mark rows that are only source-audited as such (the issue says these are source/history findings, not end-to-end certification).
• Link the existing Visual Export reports (feedback-plugin-visual-export#6 and Research: Evaluate chord detection approaches (chroma vs. Essentia vs. DL) #7).

Acceptance criteria

• Every API listed in Define a verifiable core compatibility baseline for current plugins #102 has a row with commit, date, dependent plugins, required/optional, and upstream/fork.
• Anyone can identify, from a commit hash, whether a plugin feature is expected to work.
• The document states clearly what is certified and what is only source-audited.

Out of scope

Cutting a release version (sub-issue 5), metadata enforcement (sub-issue 3), automated tests (sub-issue 4).