class GetEvent

Gets a duplicate handle to the shared kernel `ownership_event` whose

orthogonal signals inform clients and the system pipeline when direct

driver input access (`fuchsia.input.report.Service`) is granted or revoked:

- `Virtcon` (`target` = `virtcon: {}`): owns input iff

`InputOwnershipSignal.DISPLAY_UNOWNED` is asserted.

- `Starnix` (`target` = `view_ref`): owns direct input iff both

`InputOwnershipSignal.DISPLAY_PLATFORM_OWNED` and

`InputOwnershipSignal.INPUT_CLIENT_OWNED` are asserted.

- `SceneManager` (`target` = `platform: {}`): owns platform pipeline

input iff both `InputOwnershipSignal.DISPLAY_PLATFORM_OWNED` and

`InputOwnershipSignal.INPUT_PLATFORM_OWNED` are asserted (pauses whenever

`DISPLAY_UNOWNED` or `INPUT_CLIENT_OWNED` is asserted).

Requesting direct input ownership:

Calling `GetEvent` with `target` = `view_ref` is also how a view requests

direct input ownership; there is no separate request method. `GetEvent`

supports pre-registering a valid `ViewRef` before the view is created or

attached to the `ViewTree`. On success, the server registers the `ViewRef`

as the system-wide direct input client, immediately evaluates it against

the latest `ViewTree` snapshot if one exists, and continues evaluating it

against the single-view + full-screen criteria on every subsequent `ViewTree`

update. `INPUT_CLIENT_OWNED` is asserted only while the registered view

meets those criteria; otherwise `INPUT_PLATFORM_OWNED` is asserted.

- Registration is singleton and last-writer-wins: a successful call with

a different `ViewRef` replaces any previously registered view. This

mechanism is intended for a single trusted client replacing its own view

rather than independent concurrent components: because every `GetEvent`

call returns a handle to the same shared kernel `ownership_event`, replacing

the registered `ViewRef` does not silence earlier callers' handles when

their view is unlinked or destroyed and the new view goes fullscreen.

- If the `ViewTree` contains more than one view or overlay competing

with the registered view, the criteria are not met and ownership

falls back to the platform. Thus, when multiple views request direct

input while coexisting in the `ViewTree`, none of them is granted

direct input, regardless of which one registered last.

- Registration is tied to the lifetime of the view, not to this

channel or the returned event. Unlinking the view from the `ViewTree`

(placing it in `unconnected_views`) reverts ownership to

`INPUT_PLATFORM_OWNED` while retaining the registration, so re-linking

fullscreen restores `INPUT_CLIENT_OWNED`. Destroying the view permanently

drops the registration, at which point ownership reverts to the platform.

- Calls with `virtcon: {}` or `platform: {}` only observe ownership and

do not modify the registered direct client.

If `target` is set to an unsupported or unknown variant, the call

returns `InputOwnershipError.INVALID_TARGET`.