feat(rag): support string and UUID Qdrant point IDs

Point ids were read with as_u64() inside a filter_map, so a string id was
silently dropped and a UUID-keyed collection returned zero hits with no error.
The attach wizard therefore refused such collections and told the user to
rebuild with integer ids, which defeats the purpose of attaching to a
collection someone else already built. LangChain, a common way to populate
Qdrant, uses UUIDs by default.

The integer id was never load-bearing for this driver. DocumentId is a packed
(file, chunk) pair used positionally by the local drivers, but an attached RAG
holds no local files or vectors and every positional consumer already returns
early on it, so the id only has to survive the round trip from search back to
the content fetch. Ids that cannot make that trip as a u64 are interned behind
a synthetic handle and restored when the fetch is issued, leaving collections
that already use integer ids on exactly the path they used before.

src/rag/mod.rs

@@ -475,18 +475,6 @@ impl Rag {
             }
         }
 
-        // Point IDs are read with `as_u64()`, which yields None for a JSON string.
-        // A UUID-keyed collection would therefore return zero hits with no error,
-        // so refuse it here instead of attaching something silently broken.
-        if let Some(raw_id) = &sample_id
-            && raw_id.starts_with('"')
-        {
-            bail!(
-                "Collection '{collection}' uses string (UUID) point IDs. \
-                 Coyote requires integer point IDs. Rebuild the collection with integer IDs \
-                 (e.g. LangChain: pass ids=list(range(len(docs))) to add_documents())."
-            );
-        }
         println!("ℹ  This collection must store document text in a 'page_content' payload field.");
 
         let dim = QdrantProvider::get_vector_dimension(&host, &collection, api_key)