feat(14-01): beachcomber DropIndex and EnsureIndex for reindex tooling

- optional IndexDropper reports whether a dropped index existed; DropIndex falls back to Flush
- optional IndexEnsurer creates an empty index from its schema; EnsureIndex is a no-op otherwise
- typesense implements both (404 is already absent; ensure reuses collection creation)

docs/services/search.md

@@ -135,6 +135,15 @@ A paginated endpoint also needs to know how many documents matched. An engine th
 
 `beachcomber.Query.QueryByWeights` ranks the fields of `QueryBy`, one weight per field in the same order, as Scout's `query_by_weights` option does.
 
+## Reindexing
+
+`beachcomber.Service.Sync` pushes one model on demand; a reindex command loops over the table with it. Two helpers cover the index itself:
+
+- `beachcomber.DropIndex` drops an index and reports whether it existed, so the command can print a different message for an index that was already absent. It uses the optional `beachcomber.IndexDropper` interface; for an engine without it, it calls `Flush` and reports that the index existed.
+- `beachcomber.EnsureIndex` creates the index, empty, from the schema a `beachcomber.IndexSchemaProvider` model supplies. Call it before the loop: an `Upsert` of zero documents creates nothing, so without it an empty table leaves no index behind. It uses the optional `beachcomber.IndexEnsurer` interface and does nothing for other engines.
+
+The Typesense engine implements both.
+
 ## Typesense
 
 The Typesense engine follows the Scout Typesense wire contract, so indexes built by a WinterCMS application can be searched by the port: