[Architecture #478] Decide native-solver strategy for liblinear/libsvm-class workloads

Parent: #478. Related: #479 #480.

The architecture audit shows external-native-bound sklearn rows are the hardest class. Flow needs an explicit policy rather than accidentally comparing a simple in-house solver against decades-optimized liblinear/libsvm forever.

Evaluate three strategies per solver family: (A) optimize the pure Flow implementation to parity/lead, (B) bind the mature native library behind a Flow API with zero-copy buffers, or (C) maintain both with an evidence-backed size/target selector. Compare runtime, memory, binary/dependency footprint, portability, deterministic semantics and maintenance cost.

Acceptance: LinearSVC/SVC have a documented backend decision; benchmarks compare equivalent algorithmic contracts; no hidden Python dependency; native binding overhead is measured; pure Flow remains available where required by WASM/embedded/portability goals if that is part of supported scope.

Read parent #478 and the architecture audit first, then inspect the LinearSVC and SVC solver paths. Compare equivalent-contract benchmarks for the three proposed backend strategies, including runtime, memory, native-binding overhead, dependencies, portability, deterministic semantics, and maintenance cost. Done means the backend decision is documented, with pure Flow retained where the supported portability scope requires it.