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

- [x] I have searched the [issues](https://github.com/apache/openserverless/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\`](https://github.com/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\`](https://github.com/apache/openserverless-cli/blob/64d64963b761341bab2f08be6f7842e782d5b565/prereq.go#L249-L274). Callers therefore continue as if setup succeeded.
2. [\`downloadPrereq\` trusts the \`-\` marker before validating the actual executable](https://github.com/apache/openserverless-cli/blob/64d64963b761341bab2f08be6f7842e782d5b565/prereq.go#L204-L209).

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

Start in prereq.go at ensurePrereq and downloadPrereq, then reproduce the marker case with ops ide undeploy on Linux amd64. Add coverage for missing, empty, and non-executable files behind a version marker and for failed prerequisite propagation; done means stale markers do not bypass validation and downstream tasks stop with a useful CLI error.

Written by the indexing model from the issue text.