Fix VectorStore lifecycle management and remove premature disposal

[Copilot]

Addresses code analysis warning about undisposed InMemoryVectorStore instances while fixing an incorrect disposal pattern that would break returned collections.

Changes

• Removed premature using disposal of RedisVectorStore - The collection requires the store to remain alive; disposing immediately causes runtime failures
• Standardized VectorStore lifecycle across all types - InMemory, Redis, and Qdrant now follow consistent pattern
• Added XML documentation - Explains intentional non-disposal and recommends DI-based lifecycle management for future refactoring

Context

// Before: Redis disposed too early, breaking the collection
using (var redisVectorStore = new RedisVectorStore(database, new() { ... }))
{
    collection = redisVectorStore.GetCollection<TKey, TRecord>(name, def);
} // Store disposed here - collection unusable

// After: Consistent with other VectorStore types
vectorStore = new RedisVectorStore(database, new() { ... });
collection = vectorStore.GetCollection<TKey, TRecord>(name, def);
// Collection maintains reference to store

The VectorStoreCollection depends on the VectorStore instance - proper lifecycle management requires either DI or caller-managed disposal.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.