The checkout-pointing install is proven before anything moves

[sameera]

As a Nexus maintainer, I want the checkout-pointing install proven on the development machine first, so that the move that follows cannot leave me unable to develop Nexus.

Acceptance Criteria

• Given the install location is pointed at a checkout's authored tree, when a Nexus command is invoked, then the body that runs is the one in the checkout.
• Given an edit to a component in that checkout, when the command is invoked again with no install step in between, then the edit is in effect.
• Given the install location points at a checkout, when the version verb runs, then it reports that the location points at a checkout, and names the checkout path.
• Given the install location points at a checkout that also still has components at its own .claude/, when the duplicate check runs, then it does not report a duplicate, because it compares resolved real paths.
• Given the loop has been exercised end to end, when this story is signed off, then the readout naming the checkout the install location points at, and the output of a command proven to run from it, are both recorded on this story's issue.

Notes

The checkout-pointing mode is built in #253 as a flag on the install verb. This story is not that build — it is the verification, on the machine that develops Nexus, that the mode actually carries the maintainer's loop before that loop's current mechanism is taken away.

AC5 states the gate as an acceptance criterion so it is checkable rather than merely intended, and gives the evidence a durable home — the story's own issue — so Story 2 has something to read rather than a memory to trust.

This story builds nothing; #253 builds the mode. It exists because the demonstration is the gate, and a gate nobody recorded passing is a gate nobody passed.