Rename Installation to Instance

Follows the portal: the noun is "instance" everywhere the app says it —
UI strings, CLI output, error details, docs and comments. The wire keys
(`instance_id`, `instance_token`) and the hub route this calls move with it.

An existing cloud.json is adopted rather than refused: without the key
alias the dataclass fails to parse, which the caller swallows and reads as
"never enrolled" instead of "reconnect".

`instance_key` on a node type becomes `target_key`. It means the outside
thing a node points at, which is a different sense of the word, and keeping
both would put two meanings of "instance" in one codebase.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015YrQnKV3bnQd4K342y8tKj

docs/getting-started/index.md

@@ -53,7 +53,7 @@ Some rough tells:
 | **The thing you look at** | run history and loss curves | a dashboard, maybe on a wall |
 
 If both describe you — a lab with instruments to drive *and* models to
-fit — start with the data-science path. It is the smaller installation, and it
+fit — start with the data-science path. It is the smaller instance, and it
 grows into the other one without being reinstalled: the same engine, the same
 flows, just more of them running all the time.
 
@@ -62,7 +62,7 @@ flows, just more of them running all the time.
 Whichever door you came in:
 
 - **Flows are files in a git repository.** Every save is a commit. You can read
-  the history with ordinary git, and you can copy a flow between installations
+  the history with ordinary git, and you can copy a flow between instances
   by copying a directory.
 - **Editing is separate from running.** You edit a draft; the engine keeps
   running what was published until you publish.