Summary

Alternative to #312. That PR documented write_parallelism as primarily a memory-capping knob for wide rows and didn't mention the built-in progress bar or the tradeoffs of streaming a RecordBatchReader vs. a file-backed Dataset. This PR rewrites the Ingestion section of docs/performance.mdx instead:

• write_parallelism's main benefit is write bandwidth: more partitions means more concurrent writes, up to the CPU core count.
• Documents progress=True, which shows a live tqdm bar with throughput (MB/s) and active worker count — currently undocumented anywhere — including a sample of what the output looks like.
• Clarifies that for larger-than-memory data, scanning a file-backed Dataset is preferable to a hand-built RecordBatchReader: only a Dataset can be counted and rescanned, which lets LanceDB auto-size parallelism and retry a failed write. A reader can only be consumed once, so neither is possible.
• Narrows iterator ingestion to its actual use case — data that needs per-row work before it can be written (e.g. applying a custom transformation as you ingest) — rather than "streaming" generally, and drops the memory framing (iterator ingestion isn't about memory).
• Adds a note under iterator ingestion for setting write_parallelism manually on large inputs, since LanceDB can't auto-size it without a countable/rescannable source, including a rule of thumb — budget one unit of parallelism per ~100K rows or ~1 GB, to avoid fragmenting small datasets.

Test plan

• Read through the rendered Ingestion section for flow/accuracy
• Confirm no conflicting claims with Update from code changes: document write_parallelism on add() #312 if both are being considered