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/reference/node-types.md

@@ -5,7 +5,7 @@ editor generates from its parameter schema, so they all behave the same way.
 
 Anything here could be written as a **Function** node — that is what the
 function node is for. These exist because the same handful of shapes account
-for most of a real installation, and a rule you fill in is easier to read on a
+for most of a real instance, and a rule you fill in is easier to read on a
 canvas, and to change, than five lines of code repeated eighty times.
 
 `GET /flows/node-types` returns this list with each type's full parameter
@@ -138,7 +138,7 @@ thing configured elsewhere.
 | `start_delay` | `1.0` | how long to wait before that first emission |
 
 The scheduler: a `cron` expression here is what makes a flow run by the clock.
-It is also the most-placed node in a real installation — mostly as a button
+It is also the most-placed node in a real instance — mostly as a button
 someone presses.
 
 ### Delay & schedule