feat: improve bulk import efficiency

[emilylm]

📌 Summary

The /taxonomy-info/bulk-insert endpoint was timing out on AWS for large imports (~200 organisms took 8.5 minutes locally). The bottleneck was sequential NCBI Dataset API calls — taxonomy batches, parent lineage lookups, and organelle lookups were all processed one at a time.

---

🔄 Type of Change

• 🧹 Refactor (code change that neither fixes a bug nor adds a feature)

---

🧩 Key Changes

• Parallel taxonomy batches: all NCBI taxonomy batch requests now fire concurrently via ThreadPoolExecutor instead of sequentially
• Parallel per-organism field extraction: extract_taxonomy_fields calls (which each make parent + organelle NCBI requests) now run concurrently across all organisms in a batch
• Parallel parent + organelle lookups per organism: process_parents and organelle_ref_lookup were sequential within each organism — they are now run concurrently since they are independent
• Concurrency cap: a threading.Semaphore(10) limits concurrent in-flight NCBI HTTP requests to avoid rate-limiting

---

✅ Checklist

• Tests are passing locally / in CI
• New tests have been added for new or changed functionality
• Self-review completed
• Documentation updated (if needed)
• No sensitive data or secrets included

---

🔍 Review Notes

• The module-level related_mitos and no_mitos caches are accessed from multiple threads. CPython's GIL makes simple dict/set reads and writes safe; the only race is two threads both missing the cache for the same taxid and making redundant NCBI calls — this is harmless since the result is idempotent.
• The semaphore value of 10 is conservative. NCBI allows up to 10 req/s with an API key; tuning this value up may yield further gains if rate limiting is not a concern.

---

📎 Related Issues / Tickets

• Closes #
• Related to #