events.list and schema usability: bare null on empty result, dotted operation names, leaked validator identifier

[brodkin]

Summary

Three small, independent issues found while using the events and schema commands. Grouped for easy triage; happy to split into separate issues or PRs if you prefer.

1. events.list returns bare null on an empty result

When an events query matches no events, the command prints the literal null with exit code 0, rather than an empty result set:

$ egnyte events list --json '{"id":<latest_id>}'
null

This happens for any zero-match query, for example starting from the latest event id where nothing is newer. apiRequest returns null for an empty response body (src/lib/http.js), and cmdEventsList passes it straight to output. A caller that expects an object with an events array receives null and fails on it. Returning an empty collection, or a documented empty shape, would be safer for automation.

Worth noting because it is easy to misread as a broken folder filter. The folder filter works: a nonexistent folder returns a clear 404, and a real folder narrows results. The null is only the empty-result representation.

2. schema requires dotted operation names while help uses spaces

Help text and examples use space-separated commands such as events list. The schema index is keyed on the dotted form:

$ egnyte schema events.list      # works
$ egnyte schema "events list"    # {"error":"Unknown operation: 'events list'. ..."}
$ egnyte schema events list      # {"error":"Unknown operation: 'events'. ..."}

A user copying the documented events list form into schema gets Unknown operation. Accepting the space form, or having the error suggest the dotted form, would remove the surprise.

3. Backend validator identifier leaks in error output

An out-of-range count surfaces an internal validator identifier:

$ egnyte events list --json '{"id":<id>,"count":1000}'
HTTP 400: ... "code":"ORG_HIBERNATE_VALIDATOR_CONSTRAINTS_RANGE_MESSAGE","msg":"Value must be between 1 and 100"

The msg is useful; the class-name style code is internal and not actionable. Low priority and partly upstream of the CLI, but noted since the CLI surfaces it verbatim. (The undocumented count maximum is addressed separately in the events.list schema PR.)