`validate` always exits 0 — Invalid results are stdout-only, so exit-status CI gates pass broken documents

### Environment

`@openacr/openacr@0.3.8` (npm), Node v24.13.0.

### Steps to reproduce

Schema-invalid document (missing the required `author.email`):

```console
$ openacr validate -f invalid-schema.yaml -c node_modules/@openacr/openacr/catalog/2.5-edition-wcag-2.2-508-en.yaml
Invalid: data/author must have required property 'email'
$ echo $?
0
```

Unparseable file:

```console
$ openacr validate -f unparseable.yaml -c node_modules/@openacr/openacr/catalog/2.5-edition-wcag-2.2-508-en.yaml
Invalid: file is not in YAML format
$ echo $?
0
```

The catalog-membership failure in #363 also exits 0.

### Expected

Non-zero exit status on `Invalid:` results (and on parse failures), per the conventional CLI contract.

### Actual

`validate` exits 0 in every case; the Valid/Invalid signal is stdout text only.

### Why it matters

Any CI step gating on exit status — the standard pattern (`openacr validate … && deploy`) — silently passes invalid and even unparseable ACRs. Consumers must know to grep stdout for the literal `Valid!` string instead, and nothing documents that.

Related: #363 (bare `validate` skips catalog checks). Together these mean the safe invocation is non-obvious in two independent ways.

Start at the `openacr validate` CLI entry point and reproduce the schema-invalid and unparseable-file commands shown in the issue. Done means invalid documents, parse failures, and the catalog-membership failure from #363 produce a non-zero exit status while valid documents retain the successful status.

Written by the indexing model from the issue text.