Schedule sandbox deletion from Settings instead of hard-deleting

[hirad121]

Description

Fixes the Settings-page sandbox delete flow, which was permanently destroying
a sandbox instead of scheduling it for deletion with the 7-day grace period.
Two bugs in the same flow:

1. The confirm-delete handler called Sandboxes.delete_sandbox/2 (hard
   delete, immediate Projects.delete_project/1) instead of
   Sandboxes.schedule_sandbox_deletion/2 (soft delete — sets
   scheduled_deletion, recoverable during the grace period), even
   though the shared confirmation dialog always tells the user the sandbox
   "will be retained... before being permanently removed." The sandbox
   card's delete flow already used the correct function; only Settings
   was affected.
2. That same shared dialog's "Its N child sandboxes will also be deleted"
   warning never rendered from Settings, because the descendants prop
   wasn't being passed through. Soft-delete sandboxes with grace-period purge #4670 added this warning to the sandbox
   card path back in May but never wired it into Settings, leaving When deleting a sandbox with dependents, provide a warning #4667
   open and unaddressed since — this PR is the missing other half of that fix.

Closes #5058
Closes #4667

Validation steps

1. Open a sandbox's Settings page → Danger zone → Delete sandbox.
2. Type the sandbox name to confirm, submit.
3. The sandbox is no longer removed from the database instantly — it now
   has scheduled_deletion set and is recoverable during the grace period,
   same as deleting from the sandbox card.
4. Create a sandbox with a child sandbox, delete the parent from its own
   Settings page — the "Its child sandbox will also be deleted" warning
   now shows (previously silent, per When deleting a sandbox with dependents, provide a warning #4667).

Additional notes for the reviewer

Small, isolated diff — 3 files (settings.ex, settings.html.heex,
sandbox_settings_test.exs). Redirect target (root project's workflow page)
is intentionally unchanged — it already matches what the shared modal
tells the user, unlike the sandbox card's own redirect target for
deeply-nested sandboxes (pre-existing, out of scope here). Full test suite
passes unchanged.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our
Responsible AI Policy

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review
  with Claude Code)
• I have implemented and tested all related authorization policies.
  (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR