refactor: Import endpoint utilize DTO pattern

[dmohns]

Brief summary of the change made

This PR adds refactoring to the Import endpoints aiming to making the code base more idiomatic and (as a result) provide a better auto generated documentation.

• Utilize specific resources for returns.
• Use DTO instead of untyped arrays
• Exception handling moved to dedicated exception

Before:

After:

[!INFO]
This PR is an intermediate steps. In a second step I suggest to move to Laravel Data for even more idiomatic code organisation.
However, implementing this in a second PR.

Are there any other side effects of this change that we should be aware of?

⚠️ Breaking change: import endpoints accept one canonical payload format

What changed

All POST /api/import/* endpoints now accept exactly one request format — the data key
must be a list of items to import:

{ "data": [ { "device_info": { "serial_number": "SM-001" } }, ... ] }

Previously, the endpoints silently tolerated a second, undocumented format: an entire exported
JSON file posted under data (a "double-wrapped" payload):

{ "data": { "data": [ ... ], "meta": { "exported_at": "..." } } }

Describe how you tested your changes?

Pull Request checklist

Please confirm you have completed any of the necessary steps below.

• Meaningful Pull Request title and description
• Changes tested as described above
• Added appropriate documentation for the change.
• Created GitHub issues for any relevant followup/future enhancements if appropriate.

[beesaferoot]

Looks really good. Tested locally and not major breaking change was observed.

I noticed that we don't add the geojson data of mini-grids when we export so it shows that the mini-grid has no location when a cluster is imported.