find_source_in_db's spatial fallback search crashes on a completely empty Sources table

Start at astrodb_utils.sources.find_source_in_db, reached through ingest_source and the astrodb-ingest-sources generated script, and reproduce the first ingest against an empty Sources table with search_db=True. Confirm that the spatial fallback handles zero rows without a column-indexing crash, then check the skill instructions for the documented first-ingest workaround. Done means the empty-table case is handled or clearly documented without disrupting incremental searches.

Where: astrodb_utils.sources.find_source_in_db (via ingest_source with search_db=True), called from the astrodb-ingest-sources skill's generated script.

What happened: Ingesting the very first source into a brand-new, completely empty Sources table with search_db=True failed on every single row with "None of [Index(['ra_deg', 'dec_deg'], dtype='str')] are in the [columns]". This comes from find_source_in_db's coordinate-based db.query_region(...) fallback (reached because there's no name match yet), which appears to return a DataFrame with no columns at all when queried against a table with zero rows, so the subsequent db_name_matches[ra_col_name] access fails.

Workaround: Set search_db=False for this first bulk ingest into a fresh table — there is nothing to dedupe against yet, so skipping the search entirely is correct and cheap. This would need to be revisited (search_db=True) for any future incremental ingest into an already-populated Sources table.

Suggested change: astrodb-ingest-sources's skill instructions could note this edge case explicitly: "if this is the first ingest into an empty database, prefer search_db=False, since find_source_in_db's spatial-search fallback errors on a zero-row table rather than returning zero matches." Longer-term, the fix belongs in astrodb_utils.sources.find_source_in_db (guard the empty-table case before indexing into db_name_matches).

Reported from a gotchas.md log filed by a skill user (2026-08-28).