Add error handling for runInit in container entrypoint

[gricha]

Summary

Addresses Sentry review feedback from PR #34.

The runInit() call in the container entrypoint lacked error handling. If initialization failed (e.g., git clone failure, bootstrap script error), the container would crash and restart infinitely due to the unless-stopped restart policy, preventing SSH access for debugging.

Changes

• Wrapped runInit() in try/catch block
• Errors are logged as non-fatal
• SSH daemon still starts so users can connect and debug initialization issues

Test plan

• Existing clone test passes with new image
• bun run check passes

🤖 Generated with Claude Code

[sentry]

Bug: A new check for an existing repository directory causes an infinite initialization loop if a post-clone step fails, preventing the workspace from ever successfully starting up.
_{Severity: CRITICAL | Confidence: High}

🔍 Detailed Analysis

A new check for an existing repository directory can lead to an infinite initialization loop. If a post-clone step, such as runBootstrapScripts(), fails, the .workspace-initialized marker file is not created. On subsequent restarts, the new check at lines 86-93 will find the existing repository directory and cause cloneRepository() to return early. The initialization process will then re-run the subsequent steps, which will fail again at the same point. This leaves the workspace in a permanently broken state, unable to complete initialization without manual user intervention to remove the repository directory.

💡 Suggested Fix

The logic should be adjusted to handle this semi-initialized state. Instead of returning early if the repository directory exists, consider either deleting the directory to allow a fresh clone or making the subsequent initialization steps more robust to this condition. The previous behavior, which would fail on the git clone command itself, was more explicit.

🤖 Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: perry/internal/src/commands/init.ts#L86-L93

Potential issue: A new check for an existing repository directory can lead to an
infinite initialization loop. If a post-clone step, such as `runBootstrapScripts()`,
fails, the `.workspace-initialized` marker file is not created. On subsequent restarts,
the new check at lines 86-93 will find the existing repository directory and cause
`cloneRepository()` to return early. The initialization process will then re-run the
subsequent steps, which will fail again at the same point. This leaves the workspace in
a permanently broken state, unable to complete initialization without manual user
intervention to remove the repository directory.

_{Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 8300857}

[gricha]

Re: Sentry's second comment about "infinite initialization loop":

The current behavior is intentional graceful degradation:

1. Clone succeeds, bootstrap fails → Error is caught in entrypoint → SSH daemon starts → User can SSH in and debug
2. On restart → Clone is skipped (directory exists) → Bootstrap retries → If fails again, SSH still starts

This is better than the alternatives:

• ❌ Deleting the repo on failure would lose user's local changes
• ❌ Re-cloning every time would be slow and might fail for the same reason
• ✅ Current approach: Skip clone, retry bootstrap, always ensure SSH access

The workspace isn't "broken" - it's in a recoverable state where users can SSH in to diagnose and fix the bootstrap issue.