[CLI] Prerequisite failures are swallowed and stale markers bypass executable validation

Empieza en prereq.go, en ensurePrereq y downloadPrereq, y luego reproduce el caso del marcador con ops ide undeploy en Linux amd64. Añade cobertura para archivos inexistentes, vacíos y no ejecutables detrás de un marcador de versión, y para la propagación de prerrequisitos fallidos; el trabajo estará terminado cuando los marcadores obsoletos no omitan la validación y las tareas posteriores se detengan con un error de CLI útil.

• I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description

The CLI prerequisite bootstrap can report success even when a prerequisite installation failed, and a stale version marker can permanently hide a missing, empty, or unusable executable.

This was verified against `apache/openserverless-cli` commit `64d64963b761341bab2f08be6f7842e782d5b565`, used by OPS `0.9.1-2607111538.dev`, and is also present on the current `main` branch.

Ⅱ. Describe what happened

There are two related failure paths in `prereq.go`:

1. `ensurePrereq` prints errors from `downloadPrereq` but always returns `nil`. Callers therefore continue as if setup succeeded.
2. `downloadPrereq` trusts the `-` marker before validating the actual executable.

In the observed state:

• `~/.ops/linux-amd64/bin/coreutils-0.0.27` existed;
• `~/.ops/linux-amd64/bin/coreutils` was a zero-byte file;
• the marker caused later runs to skip installation;
• `ops ide undeploy` then emitted `"coreutils": executable file not found in $PATH` three times;
• the task finally reported the misleading secondary error `bun 1.3.14 or greater not available`, although Bun `1.3.14` was installed.

Related issue #96 covers detecting an update that leaves an old executable in place. This case is different because prerequisite errors are swallowed and a stale marker bypasses executable validation entirely.

Ⅲ. Describe what you expected to happen

• A failed prerequisite installation must make `ensurePrereq` return an error.
• A version marker must only be accepted when the corresponding executable exists and is a regular, non-empty, executable file.
• A stale marker should be removed or ignored so OPS can reinstall the prerequisite.
• Downstream tasks should not run after prerequisite setup has failed.

Ⅳ. How to reproduce it (as minimally and precisely as possible)

1. Install or initialize OPS on Linux amd64.
2. Leave `~/.ops/linux-amd64/bin/coreutils-0.0.27` in place.
3. Truncate the executable:
   ```sh
   : > ~/.ops/linux-amd64/bin/coreutils
   ```
4. Run an OPS task whose setup declares `coreutils 0.0.27`, for example:
   ```sh
   ops ide undeploy
   ```
5. Observe that prerequisite setup trusts the marker and the task continues with an unusable `coreutils`.

The same behavior can be reproduced by removing the executable while retaining the marker.

Ⅴ. Suggested fix

• Return a wrapped error from `ensurePrereq` when `downloadPrereq` fails (either fail fast or aggregate errors).
• Validate the executable before the marker fast path.
• Remove stale markers when validation fails.
• Add tests for marker + missing executable, marker + zero-byte executable, marker + non-executable file, and a failed prerequisite task propagating to the CLI exit status.

Ⅵ. Environment

• OPS CLI version: `0.9.1-2607111538.dev`
• CLI commit: `64d64963b761341bab2f08be6f7842e782d5b565`
• Task repository/branch: `apache/openserverless-task:0.9.1`
• OS/architecture: Linux amd64