feat(collection): optional progress bar for Collection.upsert (#10)

[srijanarya]

Closes #10, scoped to upsert; create_index progress is left for a follow-up as discussed in the issue.

Adds an opt-in show_progress: bool = False parameter to Collection.upsert. When enabled:

• Uses tqdm.auto, so it picks a notebook widget or a terminal bar automatically (the notebook-vs-shell problem raised in the issue).
• Reports a known total when records is Sized (list, tuple, ...), and falls back to an indeterminate bar for generators and other unsized iterables.
• tqdm is an optional extra (pip install vecs[progress]), not a new hard dependency, so pip install vecs is unchanged. Calling with show_progress=True without tqdm installed raises an ImportError with the install hint.
• Default behaviour (show_progress=False) is unchanged.

Tests added in src/tests/test_upsert_progress.py for: default creates no progress object, sized input reports the total and updates per 500-record chunk, generator input is indeterminate and still updates per chunk, and the ImportError path when tqdm is absent. Full suite run locally against supabase/postgres:15.1.1.78: 44 passed; the 3 test_adapters.py text-embedding tests fail identically on main without the sentence-transformers extra installed.

[marcosbeta23]

Went through the diff against what we discussed on #10 — solid implementation. Left one inline note about progress-bar cleanup on an exception path; everything else looks good to me.

[marcosbeta23]

Nice work overall — the show_progress scoping is clean, and tqdm.auto resolves the notebook/terminal split exactly as discussed in the issue.

One correctness note on this hunk: progress.close() (and the update() calls) only run if the per-chunk loop finishes without error. If sess.execute(stmt) raises partway through, the function exits via the exception and the bar never closes — harmless in a plain terminal, but tqdm.auto's notebook widget can be left half-rendered if that happens in Jupyter.

Since the fix needs to wrap the whole per-chunk loop rather than just these lines, something like a try/finally around the loop body (with progress.close() in the finally), or using tqdm as a context manager, would make this exception-safe. Happy to sketch it out further if useful — not blocking, but worth tightening before merge.