splitVector has inconsistent and untested behavior on timeseries collections.

8.0 (legacy timeseries — view over system.buckets):

• Running splitVector against the ts view namespace correctly errors: "Namespace testdb.ts is a view, not a collection"
• Running splitVector against system.buckets.ts directly works for some key patterns ({_id:1}, {{ {meta:1}

  }}, the full bucket index) but fails for others — the command has no explicit timeseries awareness

9.0 (viewless timeseries):

• splitVector on the ts namespace with {_id:1} silently succeeds and returns real split points — despite timeseries collections not being splittable this way
• splitVector on the ts namespace with {{ {m:1,t:1}

  }} (the index reported by getIndexes()) fails with "couldn't find index over splitting key" — inconsistent, since the index exists

• splitVector on system.buckets.ts is correctly blocked with "Direct access to timeseries buckets namespaces is not allowed anymore"

The root cause is that the SplitVector command handler has no check for timeseries namespaces. The fix should add an explicit uassert after the collection is acquired to reject timeseries namespaces with a clear error message, consistent with how other commands block unsupported collection types.

The secondary symptom — {{

}} failing despite the index existing — likely indicates that splitVector does not resolve user-visible timeseries index keys to their internal storage representation, but this is moot once the rejection is in place.

There is currently no jstest coverage for splitVector behavior on timeseries collections at all.

Proposed fix:

1. Add an explicit timeseries namespace check in split_vector_command.cpp after collection acquisition
2. Add jstest coverage for splitVector on timeseries collections (RS and sharded topologies, 8.0 legacy and 9.0 viewless)