#149, #153, #154: dialogs arrive, sit on top, and give the keyboard back

#149 - a line is typed out at about three and a half words a second, with a
scan sweep running down the panel and faint rules across it while it
decodes. The frame carries the charge while it works and settles when the
line lands; the caret is a solid write-head during the decode and only
starts blinking once it is waiting on the reader.

Two implementation notes worth keeping. The full text is set and then
REVEALED with visible_characters rather than the string being grown - a
growing string re-wraps on nearly every frame, so words jump between rows as
they are typed. And a press on a line still arriving FINISHES it instead of
dismissing it: without that, a player clicking at their usual pace skips the
second line having never seen a word of it, which is the exact thing #127
exists to prevent.

#153 - "after a dialog popup the input system is lost on keypress". Nothing
was lost; it was never delivered. A dialog stops the tree (#128), a paused
node receives no input, so a key RELEASED while the line was up never
reached the controller - keys_down kept it and the fleet flew on in that
direction once the game restarted.

NOTIFICATION_UNPAUSED arrives whatever a node's process mode is, which makes
it the one moment the question can be asked, and the physical keyboard is
the authority on what is actually held. That fixes anything that stops the
tree, not only dialogs, and the test checks it that way.

#154 - the banner was the ninth child of the UI layer and every panel came
after it, so all twelve of them drew over the top. It is the last child now,
in both scenes. Input order was never the problem and does not change: the
UI layer already sees unhandled input before the controllers do.

controllers/GameController.gd

@@ -123,6 +123,30 @@ func _held_pivot_direction() -> float:
 	return clampf(dir, -1.0, 1.0)
 
 
+# #153: "after a dialog popup the godot input system is lost on keypress. If
+# I had a key held it keeps moving in the key direction."
+#
+# It was not lost - it was never delivered. A dialog stops the tree (#128),
+# a paused node receives no input, and this controller is paused along with
+# everything else. So a key RELEASED while the line was up never reached
+# _handle_key, keys_down kept it, and the fleet flew on in that direction
+# once the game restarted.
+#
+# NOTIFICATION_UNPAUSED arrives whatever a node's process mode is, which
+# makes it the one moment where the question can be asked. The physical
+# keyboard is the authority on what is actually held down; keys_down is only
+# a record of what we were told, and it is the record that went stale.
+func _notification(what: int) -> void:
+	if what == NOTIFICATION_UNPAUSED:
+		_forget_released_keys()
+
+
+func _forget_released_keys() -> void:
+	for key in keys_down.keys():
+		if not Input.is_key_pressed(key):
+			keys_down.erase(key)
+
+
 func keyboard_direction() -> Vector2:
 	var dir: Vector2 = Vector2.ZERO
 	for key in KEY_DIRECTIONS: