`parallel=True` does not fully reach `QuasisepSolver.condition`, making conditioning ~77x slower on GPU than serial on CPU

PR #269 works as advertised for the vector-facing operations, and log_probability with parallel=True is 322x faster on GPU than on CPU (though it performs about the same as parallel=False on CPU).

However, the new parallel methods only partially reach condition, and the conditioned GP that comes back doesn't inherit the parallel flag.

I noticed this when benchmarking this new functionality against smolgp. See on that page the benchmarking plots for the likelihood and conditioning calls, for instantaneous data.

Environment

• tinygp 0.3.2.dev13+g5302d5a1a (includes #269)
• jax / jaxlib 0.9.2, float64 enabled
• GPU: NVIDIA RTX 6000 Ada, 48 GB · CPU: Intel Xeon w5-3435X (32 cores)
• Kernel: tinygp.kernels.quasisep.SHO (J = 2), sorted 1-D inputs

Measurements

Median of 7 repeats, each in a fresh process, timed around block_until_ready() and excluding JIT warm-up. Seconds.

Issue

• The X_test=None branch of QuasisepSolver.condition ignores self.parallel:
  https://github.com/dfm/tinygp/blob/5302d5a1ae47ad9ff3fe857eee4cbbebbc1c5637/src/tinygp/solvers/quasisep/solver.py#L125-L129
  QSM.__matmul__ (core.py) has no keyword to pass one and dispatches to ops.qsm_mul, and gram() is self.transpose() @ self, so three total sequential scans occur.

• gp.condition constructs the returned GaussianProcess without forwarding solver kwargs, so cond.solver.parallel is False even when gp.solver.parallel is True, affecting all subsequent calls with the conditioned GP object.

Start with src/tinygp/solvers/quasisep/solver.py at the X_test=None branch of QuasisepSolver.condition, then inspect QSM.matmul and ops.qsm_mul in core.py. Trace gp.condition to see how the conditioned GaussianProcess is constructed. Done means conditioning honors the solver's parallel setting and the returned conditioned GP preserves it for later calls; compare against the issue's conditioning benchmarks.