Validator ergonomics for consumer repos: validate CLI exits 0 on stub, validate.py takes one file, default schema path assumes repo layout

## Summary

Three small friction points that show up when you *consume* the spec from your own repository — vendoring `core-spec/osi-schema.json` and `validation/validate.py` into a repo that holds domain models — rather than working inside `apache/ossie` itself.

All three are on `main` as of today.

### 1. `ossie validate` exits 0 while printing `not yet implemented`

`cli/cmd/validate.go`:

```go
var validateCmd = &cobra.Command{
Use: "validate [flags] [...]",
Short: "Validate one or more OSSIE YAML or JSON files",
Args: cobra.MinimumNArgs(1),
RunE: runValidate,
}

func runValidate(cmd *cobra.Command, args []string) error {
fmt.Fprintln(cmd.OutOrStdout(), "not yet implemented")
return nil
}
```

`ossie validate broken-model.yaml` prints one line and **exits 0**. Dropped into a CI step, that is indistinguishable from a pass — the one failure mode worth avoiding in a validation command. The help text also advertises `[...]`, `--strict` and `--output`, none of which do anything yet.

Suggestion: return a non-zero error (or mark the command hidden / `Deprecated`) until it is wired up.

### 2. `validation/validate.py` accepts exactly one file

```python
if len(args) > 1:
if len(args) == 3 and args[1] == "--schema":
schema_path = Path(args[2])
else:
print("Usage: python validation/validate.py [--schema ]")
sys.exit(1)
```

So `validate.py models/**/*.yaml` fails with a usage error rather than validating the set. Any repo with more than one model ends up wrapping it in a shell loop, which loses the aggregate summary and makes "did everything pass?" a matter of collecting exit codes by hand.

Suggestion: accept N paths, validate each, print a per-file PASS/FAIL, and exit non-zero if any file failed.

### 3. The default schema path assumes the upstream repo layout

```python
schema_path = Path(__file__).parent.parent / "core-spec" / "osi-schema.json"
```

Vendored as `scripts/validate.py` in a consumer repo, that resolves to `/core-spec/osi-schema.json` — a directory the user never created. `--schema` solves it, but the first-run error (`Error: Schema not found: …/core-spec/osi-schema.json`) points at a path nobody chose, which is a confusing place to start.

Suggestion: keep the current default, then fall back to `./schema/osi-schema.json` and/or an `OSSIE_SCHEMA` environment variable before erroring — and mention `--schema` in the error message.

## Context

I hit these while putting together a scaffold for consumer repositories. The workaround is a `Makefile` that loops per file and always passes `--schema`, which works fine but is the sort of thing every consumer will end up reinventing.

Happy to send a PR for any or all of these if the direction sounds right — please say which of the three you'd take, and whether the Go CLI is expected to absorb the Python validator's job eventually (that would change what's worth fixing in `validate.py`).

Read cli/cmd/validate.go and validation/validate.py first, then run the documented validate examples against one and several model files. Confirm the chosen scope for the Go CLI versus the Python validator, including the schema lookup behavior. Done means consumer-repository validation reports each file clearly and returns a failing status when validation or setup fails.

Written by the indexing model from the issue text.