Refactor MonitoringTarget.target_name to remove data overloading

[timothyfroehlich]

The MonitoringTarget.target_name field is currently overloaded, storing different types of data depending on the target_type:\n- For location targets: Stores the human-readable name (e.g., "Austin Pinball Collective").\n- For city and latlong targets: Stores the coordinate string (e.g., "30.26715,-97.74306" or "30.26715,-97.74306,5").\n\nThis overloading can lead to confusion and bugs, as demonstrated by the recent fix in src/cogs/runner.py.\n\nProposed Solution:\nIntroduce a new column, e.g., coordinates_data (VARCHAR), to store the coordinate strings for city and latlong targets. The target_name column would then consistently store only the human-readable name for all target types.\n\nThis would involve:\n1. A new Alembic migration to add the coordinates_data column.\n2. A data migration to copy existing coordinate data from target_name to coordinates_data for city and latlong targets.\n3. Updating src/models.py to reflect the new schema.\n4. Updating src/cogs/runner.py and src/api.py (and potentially other files) to use the new coordinates_data column for coordinate-based lookups.\n5. Updating docs/DATABASE.md to reflect the new schema and clarify field usage.

[timothyfroehlich]

✅ RESOLVED - Issue fixed by database schema modernization

Evidence:

• Database now uses clean 'display_name' field consistently
• No more data overloading in target_name field
• Proper separation of concerns in schema design

Schema verification:
The monitoring_targets table now has proper display_name field without data overloading.

Resolution:
The database schema has been modernized to eliminate the target_name overloading issue. The field now consistently stores human-readable names while coordinates are properly separated.

Resolved in monitoring loop investigation: #92