docs(collection): describe what create_index actually does

[skritosss]

What kind of change does this PR introduce?

Docs update. No functional change.

What is the current behavior?

The Note block on Collection.create_index describes a multi-step process: create a new table, sample rows into it, build the index there, copy everything over, drop the original, rename. It also warns that dependent views may need to be dropped first.

The current implementation does none of that. create_index runs drop index (when replace is true) and a single create index on the collection's own table. clone_table, from_select and on_conflict_do_nothing no longer appear anywhere in collection.py.

The stale warning about dependent views is the part most likely to mislead — the underlying table is not recreated, so views are unaffected.

What is the new behavior?

The Note describes what the method does today, plus three things worth knowing:

• how IndexMethod.auto picks between HNSW and IVFFlat
• the n_lists formula used when no index_arguments are given
• that CREATE INDEX is not run concurrently, so writes are blocked for the duration of the build

Additional context

Docstring only, no code touched — no new tests, coverage unaffected.

Noticed while looking at #10: the create_index half of that issue points at the copy loop that no longer exists, so a progress bar there would need a different approach — polling pg_stat_progress_create_index from a second connection, assuming pgvector fills in the counters for ivfflat/hnsw. Happy to open a separate issue for that if it's useful.

Used Claude (Anthropic) to review the code and draft this change.