look verb: the camera, and what the crosshair is on

[Flatts3000]

The ask

Expose what the player is looking at, and the camera the shot is actually taken from.

What is already reachable, measured rather than assumed

I checked each of these against a running client before proposing anything, because the section 8 bar
is "anything a command can already do is out of scope":

Wanted	/data get entity @s ...	Verdict
position	[6000.5d, 120.0d, 6000.5d]	out of scope
rotation	[110.1f, 41.15f]	out of scope
velocity	[0.0d, 0.272d, 0.0d] while levitating	out of scope
on ground	0b	out of scope

Velocity is the surprise. I expected Motion to read zero for a player, since movement is
client-authoritative, and it does not: it reports real velocity. So a telemetry verb for player
position, rotation, velocity or ground state would duplicate a command, and should not be built.

What is genuinely not reachable

What the crosshair is on. There is no vanilla raycast command. Minecraft.hitResult is a public
field carrying the block position and face, or the entity, plus the distance, and it respects reach,
fluid rules and entity hitboxes. The nearest command approximation is stepping along ^ ^ ^n with
anchored eyes and testing each step, which is not the same thing and is painful to write.

The camera, which is not the player. In third person, spectator or any detached view, the shot is
taken from somewhere the player entity is not. Camera exposes position(), xRot(), yRot(),
getFov(), getRoll() and isDetached(). For a tool whose main job is framing screenshots, "where
was this actually shot from" is a question nothing can currently answer.

Proposal

One verb, client-side, reporting only what commands cannot:

{"verb": "look"}
{"ok": true,
 "camera": {"pos": [6000.5, 121.6, 6000.5], "yaw": 110.1, "pitch": 41.2, "fov": 70.0,
            "detached": false},
 "hit": {"type": "block", "pos": [6000, 118, 6002], "face": "up", "distance": 3.4}}

Deliberately no player position, rotation or velocity: cmd already answers those, and duplicating
them is how a small tool stops being small.

Related, and it moves #13

Asking "what block is that" turns out not to be command-reachable either. /data get block on an
ordinary block refuses with "The target block is not a block entity"; it only works where there is a
block entity. Naming an arbitrary block is only possible by guessing and testing with
/execute if block. See the comment added to #13, whose central question was whether structured
world queries duplicate a command. For plain blocks they do not.

This also means gamebridge probe is broken for ordinary blocks today, which nobody had noticed.