docs: opt-in EnableFast lane + contributor rules of engagement

[akaszynski]

Summary

Documents the opt-in fast-filter approach established by the EnableFast PR stack (#81–#84) and rewrites CONTRIBUTING.md with the rules of engagement for performance work.

Targets main so it's independently mergeable (docs-only; describes the convention the stack follows).

README

New lever "Opt-in fast lane — fvtk.EnableFast()" under the runtime-speed levers:

• the FastModeEnabled() / FVTK_FAST runtime toggle (read live, no rebuild);
• the two flavours — RunFastFilterParallel order-relaxed threading, and FastModeEnabled()-gated vendored OpenMP kernels (pyvista-algorithms, MIT; non-unity TUs, FVTK_HAVE_OPENMP-guarded, fall back to stock for unsupported input);
• the landed filters: cutter, contour (normals-off), vtkDataSetSurfaceFilter, vtkStaticCleanUnstructuredGrid, vtkCleanPolyData;
• the order_relaxed / points_relaxed validation modes + the engagement check (a relaxed test passes on the byte-exact fallback too, so it can't alone prove the kernel ran).

Cross-referenced from Parity & validation (the bit-exact gate).

CONTRIBUTING

Replaces the stale stock-VTK GitLab boilerplate with fvtk's actual workflow and the rules of engagement:

• Bucket 1 — byte-identical → may be default-on (needs a maxULP=0 proof).
• Bucket 2 — correct but not byte-identical → MUST be opt-in behind EnableFast(), validated by the relaxed gate + engagement check.
• Order is negotiable; positions and values are sacred. Different values — even last-ULP, e.g. a different averaging algorithm — are not admissible as a drop-in (a tolerance gate would mask a real divergence).
• Add-an-opt-in-fast-filter checklist + build/validate/PR conventions; never push to main.

🤖 Generated with Claude Code

[akaszynski]

Merged to main via fast-forward (3174090). The documented EnableFast filters (surface, static-clean UG, cleanpoly) are all live on main.