docs: define support tiers for language bindings and platforms #400

Problem

Minigraf ships eight binding or packaging targets (Python, Node, browser WASM, WASI, JVM, Android, Swift, C), each with its own repo and release pipeline, and one maintainer runs them all. Traffic data for 2026-09-05 to 09-23 shows almost no outside visits to any binding repo. Most had only one visitor in two weeks. Their clones are nearly all CI.

Every data-integrity fix and format change (v8) has to go through every binding. This spreads effort away from the core storage engine, which is where the risk is. It also makes "production-ready" unclear: production-ready for which binding?

Ask

Write down support tiers in the README and PHILOSOPHY.md:

• Tier 1: fully tested, and released at the same time as every core release. Suggested: the Rust crate, and Python (used by temporal_reasoning).
• Tier 2: built and smoke-tested, released on a best-effort schedule, marked experimental. Suggested: Node, WASM/WASI, JVM, Android, Swift, C.
• Rule for promotion: a binding moves to Tier 1 when real users need it, for example issues from outside users or known dependents.
• State which OS and filesystem combinations are Tier 1, for example Linux ext4/xfs, macOS APFS and Windows NTFS on local disk, with NFS listed separately.

Philosophy check

This fits "Do less, do it perfectly". No binding is removed. It only makes clear what "supported" means.