CLI: reader-backed on-chain images receive contradictory integrity reporting

Release-candidate contract on Arbitrum Sepolia: `0x386391C0fD9098F7FD07Ea5F8fFe97E2587adf86`.

## Observed contradiction

The successful deploy prints:

```text
on-chain content commitment: keccak256 of the served image
```

But `abx verify` reports:

```text
no content commitments on this project
```

and returns `contentIntegrity: "no-commitments"` with no content checks.

The token uses the `reader` representation. `verifyProject` intentionally hashes only `keccak256` and `sha256` representations, and the existing availability test explicitly classifies `reader` as neither hash-committed nor pointer-only. A direct end-to-end comparison still succeeded: the managed service returned the original 683 SVG bytes with an identical SHA-256 digest.

## Expected

Use one internally consistent description of the guarantee:

- If reader-backed data derives integrity from the on-chain reader/storage itself, deploy should not claim a separately verifiable keccak commitment, and `verify` should positively identify the content as on-chain/self-resolving rather than saying there is “nothing to serve.”
- If the CLI intends the displayed `contentHash` to be a verifiable commitment, persist/derive the expected digest and have `verify` check it.

Whichever model is intended, add regression coverage ensuring deploy and verify do not make contradictory integrity claims for `reader` and fastlz-backed `reader` images.

## Likely locations

- `packages/cli/src/commands/deploy.ts`: post-deploy commitment message
- `packages/cli/src/commands/project.ts`: no-commitments/availability wording
- `packages/token-api/src/server.ts`: `verifyProject`