Implement resume session API with kernel recreation (STOPPED to PENDING)

Implement resume functionality that transitions a STOPPED session back to PENDING with new kernel and resource allocation creation.

Resume flow:
1. Validate session is in STOPPED state
2. Create new KernelRow(s) from existing SessionRow config (images, environ, vfolder_mounts, bootstrap_script, startup_command, etc.)
3. Create new resource_allocations for the new kernels
4. Transition session status: STOPPED → PENDING
5. Existing scheduler handles PENDING → SCHEDULED → ... → RUNNING

Key consideration:
- Resource availability is NOT guaranteed (same as new session creation)
- Must handle case where resume fails due to resource shortage (stays in PENDING, user can cancel)

Key files:
- manager/api/rest/session/handler.py (new resume handler)
- NEW: manager/services/session/actions/resume_session.py
- manager/services/session/service.py (resume_session method)
- NEW: manager/api/gql/session/resolver/resume.py
- manager/api/gql/schema.py (mutation registration)
- manager/models/kernel/row.py (KernelRow creation)
- manager/repositories/scheduler/types/session_creation.py (reference)

## Success Criteria
- [ ] REST: resume stopped session → 204, session status becomes PENDING
- [ ] REST: resume non-stopped session → 400/409 error
- [ ] GQL: resumeSession mutation works equivalently
- [ ] New KernelRow created with config from SessionRow (images, environ, vfolder_mounts)
- [ ] New resource_allocations created for new kernels
- [ ] Session proceeds through scheduler: PENDING → SCHEDULED → ... → RUNNING
- [ ] Resource shortage: session stays PENDING (user can cancel)
- [ ] pants check passes for affected packages

JIRA Issue: BA-4963