fix(cli): surface framework success:false errors instead of reporting 'completed' #2315

Summary

`wheels migrate latest`, `wheels seed`, `wheels migrate info` all report success regardless of the framework's actual response. The HTTP call to `/wheels/cli?command=…` returns a JSON body with `success: false` and a specific error message; the CLI ignores both and prints a green check.

Repro (fresh-VM, brew-installed wheels 0.3.7 — pre-fix-wave)

```
$ wheels new blog && cd blog && wheels start
$ wheels migrate latest
Migration latest completed.

$ ls -la db/development.sqlite
-rw-r--r-- ... 0 bytes development.sqlite

$ curl -s 'http://localhost:8080/wheels/cli?command=info&format=json'
{"MESSAGES":"org.osgi.framework.BundleException: The OSGi Bundle with name [org.xerial.sqlite-jdbc] is not available locally...",
"success":false,
"wheelsVersion":"0.0.0-dev",
"datasource":"blog"}
```

The CLI saw a 200 with `success:false` and translated that into "Migration latest completed." The user has no way to know anything went wrong without manually probing the framework endpoint.

`wheels seed` is slightly better — it prints `Seeding failed: unknown error` — but "unknown" is not actionable when the framework returned a specific message.

Expected

When the framework returns `success: false`, the CLI should:

1. Exit non-zero
2. Print `MESSAGES` (or the relevant error payload) to stderr
3. Distinguish "no migrations to run" (success:true, idempotent) from "migrations errored" (success:false)

Suggested fix

In the CLI HTTP wrapper (likely in `cli/lucli/Module.cfc` migrate/seed handlers), check the parsed JSON for `success === false` and reraise with the `MESSAGES` payload. Treat 200-with-success-false as a hard error.

Why this matters

This bug is the meta-bug that hid issue #1 (missing SQLite JDBC) for so long. Every fresh-VM tester saw a green check, then was confused when their app couldn't talk to the database. Fixing the silent-success path makes the next class of cliffs self-diagnosing.

Source

Surfaced in fresh-VM onboarding journal, 2026-04-25. See also the fixes already in `develop` (#2307, #2304) which address adjacent symptoms but not the underlying CLI swallowing.