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

backend/tests/flow/test_dashboards.py

@@ -423,7 +423,7 @@ def test_an_unbound_setting_is_just_its_value():
 
     No message means nothing to type-check and nothing for a panel to be
     entitled to — and a name this build does not know is left alone rather
-    than refused, so an older installation reads a newer document.
+    than refused, so an older instance reads a newer document.
     """
     defn = DashboardDef(
         name="house",
@@ -523,7 +523,7 @@ def test_a_chart_of_runs_must_say_which_runs_and_which_metric():
 
 
 def test_a_document_written_as_pages_is_read_as_one_grid():
-    """Stored dashboards live in each installation's repository.
+    """Stored dashboards live in each instance's repository.
 
     So the old shape is normalised on the way in rather than migrated, and a
     placed second section keeps its arrangement instead of piling onto the