Deleting a sandbox from Settings destroys it immediately, though the dialog promises 7 days

Lucy noticed, while working on the "scheduled for deletion" concept, that the two ways to delete a sandbox don't behave the same. Delete from the trash icon on the sandbox card and the sandbox shows up under "Scheduled for deletion". Delete from Settings > Setup and it never appears there.

The reason turns out to be worse than a missing row in a list. The settings page deletes the sandbox straight away and permanently. It also takes every sandbox below it, and everything they hold: workflows, jobs, work orders, dataclips, collaborators, credential links, collections. None of it is recoverable. And the dialog it shows is the same shared component the card uses, so it tells you the sandbox will be kept for 7 days and that you can restore it from the list. On this path that isn't true.

The same dialog also quietly loses its warning about children. The card passes the descendants that will go with the sandbox, so you see them listed. Settings passes none, so the warning is hidden on the one path that actually destroys them.

How we got here, as far as I can tell from the history. When the settings page was made sandbox-aware (#4632, April) hard delete was the only sandbox delete we had, so wiring it up that way was right at the time. Soft delete with the grace period arrived about a week later (#4670) and only touched the sandboxes list screen. The retention wording went into the shared dialog in that same change, which is how settings ended up making a promise it doesn't keep. So this isn't old code that predates sandboxes; it's a change that updated one of two callers.

Worth noting root projects are fine on this same page: they go through the project deletion modal and are scheduled, not destroyed. It's only sandboxes that lose the grace period here.

Where to look:

• lib/lightning_web/live/project_live/settings.ex:475 — the settings handler, and the only place left that still calls the hard delete
• lib/lightning/projects/sandboxes.ex:499 — the soft delete that the card and the collaborative editor both use
• lib/lightning_web/live/project_live/settings.html.heex:296 — where the dialog is rendered without its descendants

What I think we want: settings should schedule the deletion like every other surface, and pass the descendants so the warning shows up. That makes the three delete paths agree and lines sandboxes up with how projects already behave on this page.

Two things to watch when fixing it:

• the existing settings tests probably assert the immediate delete, so they'll need to move with it
• confirm the hosted deployment doesn't swap in a different project hook with its own behaviour

One thing this is not. We wondered whether it explained the merge failure a user hit recently, where a sandbox wouldn't merge because the sandbox it was created from had been deleted. It doesn't. On this path the child would have been destroyed too, and the parent couldn't have been restored afterwards. That's a separate problem about merging when something above you is scheduled for deletion, and it needs its own issue.

Related to OpenFn/lightning#4852. Keeping it outside the epic, same as OpenFn/lightning#4919.

Start with the settings handler at lib/lightning_web/live/project_live/settings.ex:475, the soft-delete implementation at lib/lightning/projects/sandboxes.ex:499, and the dialog in settings.html.heex:296. Run the existing settings tests, update their expectations for scheduled deletion, and verify that the dialog displays descendants and the sandbox follows the same seven-day behavior as the other deletion paths.