Vector stores: extract a backend interface behind the store engine

[JGoutin]

The vector store engine and its routes are backend-neutral in shape but not in structure:
one module holds both the bookkeeping and the Amazon S3 Vectors calls, the routes import
its private functions by name, and the filter dialect and score normalisation are written
against S3 Vectors specifically. Nothing else can be plugged in without rewriting the
callers.

That is the right shape for one backend and the wrong one for two. It only becomes worth
paying for when a second backend is actually wanted — recorded here so the decision is
deliberate rather than discovered.

Refactor: a VectorIndex protocol (create, delete, put, get, delete vectors, query) with
the S3 Vectors implementation behind it; filter translation and score conversion become
the backend's responsibility, since each expresses them differently; chunking becomes a
declared backend capability, because a backend that chunks on ingestion cannot honour a
per-request chunking strategy. The offline tests currently substitute private module
attributes, so they would parametrise over a fake implementation of the protocol instead.

Assessment recorded during the 1.16 review: Amazon Bedrock Knowledge Bases is not the
second backend to build this for. The classic generation caps at 100 knowledge bases per
account, which cannot express a store-per-caller API; the managed generation fits
structurally but costs roughly $1,000 per million searches against roughly $5 on S3
Vectors, and cannot express per-file chunking, chunk listing or normalised scores.
Knowledge Bases remain the right backing for the read-only file_search tool (#105),
which is a different problem.

[JGoutin]

Assessed vector search for Amazon DynamoDB (GA 5 Aug 2026, all commercial Regions plus GovCloud) as the second backend this protocol would be built for. It does not qualify, and the reason is worth recording here because it changes what the protocol has to declare.

The filter contract is the blocker. This API promises eight operators (eq ne gt gte lt lte in nin) plus and/or composition, over attribute keys the caller invents per file at request time. DynamoDB's SearchConditionExpression supports = only — the documentation states comparison, range and set-membership operators are "not yet available" — and every filterable attribute must be declared in the index schema when the index is created, capped at 18. There is no schema to declare when the keys arrive with the request. Over-fetching and filtering in-process breaks max_num_results, which would silently under-return.

Deletion is the second problem: with 5 vector indexes per table, a store cannot own an index, so deleting one means BatchWriteItem-ing every chunk instead of a single DeleteIndex.

Cost, on the same 10 GB / 1M-searches workload used for the Knowledge Bases comparison: S3 Vectors ~$5/month, DynamoDB ~$47, Bedrock Knowledge Bases ~$1,000. DynamoDB's search line is metered per GB examined, so unlike S3 Vectors' flat per-query price it grows with corpus size.

Two corrections this implies for the protocol as scoped above:

1. It declares chunking as a backend capability but not filtering. As written it would admit a backend like this one and then fail at request time. A backend must declare the filter operators it can express, and the engine must refuse — or degrade explicitly — rather than discover the gap mid-search.
2. The genuine DynamoDB win is in the bookkeeping layer, not the index: store, file and batch records are conditional-write JSON in S3 today, and single-digit-millisecond consistent reads would suit them. That is a separate piece of work from this issue, and worth costing on its own.

What would change the assessment: AWS adding the full operator set and schemaless filter attributes. The docs' "not yet available" suggests the first is on the roadmap; the second is the one that actually matters.