vector: implement drop_index and have DeleteIndex drop the data (#12204)

* vector: implement drop_index in the engine

The RPC was a stub; it now resolves the table's vended location and
removes every object under it through the same credential path open uses.
A table the catalog can no longer describe is already dropped, so the call
stays idempotent.

* s3vectors: drop index data after the catalog delete

DeleteTable carries the delete authorization, so it runs first; the engine
DropIndex then removes the data under the index's location. NotFound and
Unimplemented are tolerated so an index whose data went away with the
catalog entry, or an older engine, still answers 200.

* s3vectors: let the catalog delete carry the index data removal

A vector index is colocated: the catalog entry sits at the dataset root,
so DeleteTable's recursive delete already removes entry and data. The
engine DropIndex call afterwards could only ever describe a missing or
recreated record — a no-op in the common case, and a delete of a
replacement index's files when the name was reused in between.

seaweed-vector/crates/server/src/service.rs

@@ -325,10 +325,16 @@ impl VectorService for VectorServer {
 
     async fn drop_index(
         &self,
-        _request: Request<pb::DropIndexRequest>,
+        request: Request<pb::DropIndexRequest>,
     ) -> Result<Response<pb::DropIndexResponse>, Status> {
-        // Dropping is a catalog decision; the gateway deletes the table record.
-        Err(Status::unimplemented("drop through the catalog"))
+        let req = request.into_inner();
+        let table = req
+            .table
+            .ok_or_else(|| Status::invalid_argument("missing table"))?;
+        dataset::drop(&self.client, &table.id, &self.fallback)
+            .await
+            .map_err(internal)?;
+        Ok(Response::new(pb::DropIndexResponse {}))
     }
 
     async fn put_vectors(