Replace exception-based control flow with return codes for CLI errors

Problem

The devfile gem currently uses exceptions (Devfile::CliError) for control flow logic when CLI commands fail. This causes issues with error tracking in Sentry, as exceptions raised from within the gem are reported to Sentry even when they are rescued higher in the Rails application stacktrace.

Current Behavior

When a CLI error occurs in the gem:

1. The gem raises a Devfile::CliError exception
2. Sentry captures this exception (even though it's later rescued in Rails code)
3. The exception appears in Sentry reports with handled=true flag
4. This creates noise in error tracking and makes it difficult to distinguish between actual errors and expected control flow

Example

The error was observed in the DevfileParserGetter in GitLab Rails:

• Location: ee/lib/remote_development/workspace_operations/create/desired_config/devfile_parser_getter.rb
• The code rescues Devfile::CliError but Sentry still reports the exception
• Sentry issue: https://new-sentry.gitlab.net/organizations/gitlab/issues/2620621/

Proposed Solution

Replace exception-based control flow with return codes or result objects that indicate the success/failure status of CLI calls.

Instead of:

raise Devfile::CliError, "Command failed"

Return a response object that indicates:

• Success/failure status
• Error code from the underlying CLI call
• Error message (if applicable)
• Any relevant output or context

This approach:

• Follows Ruby best practices (exceptions for exceptional cases, not control flow)
• Prevents unnecessary Sentry noise
• Makes error handling more explicit and predictable
• Improves the gem's API design

Additional Context

• Discussion thread: https://gitlab.slack.com/archives/C093VPLM53L/p1762357006002449?thread_ts=1762274188.965779&cid=C093VPLM53L
• Related to workspace operations in GitLab Rails application
• The handled=true flag in Sentry indicates the exception was caught, but it still creates tracking overhead

cc @cwoolley-gitlab @vtak @ashvins @adebayo_a

This issue is created by GitLab Duo Agent Platform.