Rescue paused E2B sandboxes before the 30-day cliff

Every morning at 8am, scan my paused E2B sandboxes and rescue the ones about to be auto-deleted. E2B keeps paused sandboxes for up to 30 days and then permanently destroys them, which silently kills snapshotted state from long-running experiments, RL training runs, and in-progress agent sessions. I want to know about it before that happens.

Trigger: cron, daily at 8am in my local timezone.

What the agent should do each run:

1. Use the E2B List Sandboxes operation, filtered to the paused state, to pull every paused sandbox on the team. Paginate through all pages.

2. For each paused sandbox, call E2B Get Sandbox Lifecycle Events to find the most recent paused event. Use that timestamp as the pause time and compute days_remaining = 30 minus days since the pause.

3. Group results by owner (read the owner from the sandbox metadata, falling back to an Unassigned bucket if none is set) and by template ID. Flag anything with seven days or fewer remaining as urgent.

4. Post one tidy digest to a Slack channel I choose, using the Slack Bot Send a Message operation. The digest should list each at-risk sandbox with its sandbox ID, template, owner, age (days since pause), and days remaining. Sort urgent items first, then group the rest by owner. Keep it to a single message with Slack markdown formatting.

5. For every urgent sandbox (seven days or fewer remaining), open a Linear ticket using the Linear Create Issue operation in a Linear team I pick. Assign the ticket to the matching Linear user for that owner (match by email or by a configured owner-to-Linear-user map). The ticket title should be along the lines of "Decide on paused E2B sandbox <sandboxID>". The description should ask the owner to either resume the sandbox to extend it or kill it to release the snapshot, and should include the sandbox ID, template, days remaining, pause timestamp, and a link to the Slack digest message that was just posted.

6. Dedupe: before creating any Linear ticket, use Linear Search Issues to look for an existing open issue whose title or description references the same sandbox ID. If one already exists, skip creating a new ticket. Still mention that sandbox in the Slack digest (with a note that an open ticket already exists) so it does not disappear from view.

7. If there are zero paused sandboxes at risk, still post a short Slack message confirming the sweep ran and found nothing to rescue, so I know the workflow is alive.

Output: one Slack digest per run, plus a deduped backlog of Linear decision tickets, so no paused work ever silently expires without the owner explicitly choosing to resume it or kill it.