Move cluster geo_json to GeographicalInformation

[Zhey-on]

Closes #1261

Summary

This PR moves cluster geometry storage from clusters.geo_json to geographical_informations.geo_json, making GeographicalInformation the source of truth for cluster map data while preserving the existing API contract that still exposes cluster.geo_json to the frontend.

This keeps the current frontend behavior intact, but aligns cluster geo data with the broader data-model consolidation described in #945.

Why this change

Issue #1261 points out that cluster geo data is inconsistent with the rest of the model structure because it is stored directly on the clusters table.

By moving that payload into GeographicalInformation, cluster geometry follows the same ownership pattern already used elsewhere and becomes easier to evolve without keeping location data split across multiple places.

What changed

• Added a tenant migration that:
  • adds geo_json to geographical_informations when missing,
  • copies existing clusters.geo_json values into related geographical_informations records,
  • creates missing GeographicalInformation rows for clusters that already have geometry,
  • drops the legacy clusters.geo_json column after the migration.
• Added a rollback path that restores clusters.geo_json, copies data back from geographical_informations, and removes the new relation column.
• Added a location() morph-one relation on Cluster.
• Added a geo_json accessor on Cluster and appended it to serialization so the API response shape remains backward compatible.
• Added geo_json casting on GeographicalInformation.
• Updated ClusterService to:
  • eager-load cluster location data,
  • read cluster geometry from the related GeographicalInformation,
  • create the related geo record when a cluster is created with geo_json input.
• Updated ClusterFactory, ClusterSeeder, and AgentSellApplianceTest so they work safely before and after the migration and populate cluster geometry through the relation.
• Kept transitional compatibility in the backend by conditionally writing the legacy clusters.geo_json only while that column still exists, which allows the code to run safely across pre-migration and post-migration states.

Compatibility notes

• No frontend API contract changes are required.
• Existing consumers that read cluster.geo_json continue to work.
• The actual persisted source of truth becomes geographical_informations.geo_json.

Validation

I validated the change in the local Docker environment with the following checks:

• docker compose exec -T backend-dev php artisan migrate-tenant:drop-demo-company
• docker compose exec -T backend-dev php artisan migrate:fresh --seed
• Verified the tenant schema after migration:
  • clusters.geo_json is no longer present
  • geographical_informations.geo_json is present
• Verified runtime behavior via Tinker:
  • clusters resolve geo_json through the related location
  • seeded clusters have related GeographicalInformation records with geometry

Test note

I also ran:

• docker compose exec -T backend-dev php artisan test tests/Unit/AgentSellApplianceTest.php

That test currently fails because it expects HTTP 201, while the endpoint on main already returns the default 200 response from ApiResource. The failure is therefore pre-existing and not introduced by this refactor.