#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.

tests/test_dialog_pause.gd

@@ -152,6 +152,14 @@ func _process(delta: float) -> bool:
 			print("the wave clock did not advance")
 
 			# --- D. the press acknowledges, and does nothing else ----
+			# #149: a line arrives a character at a time, and a press on one
+			# still arriving finishes it rather than dismissing it. The
+			# banner types while the game is stopped - it is the one node
+			# still running - so a second of frozen world is more than
+			# enough for this line to have finished on its own. Finished
+			# explicitly here so the press below is unambiguously the
+			# acknowledging one; the typing itself is test_dialog_typing's.
+			narration.finish_typing()
 			_press_button()
 			if presses != 0:
 				return _fail("the build button fired while a dialog was up")
@@ -166,6 +174,7 @@ func _process(delta: float) -> bool:
 				return _fail("the game restarted with a line still on screen")
 			print("a second queued line keeps the game stopped")
 
+			narration.finish_typing()
 			_press_button()
 			if presses != 0:
 				return _fail("the build button fired on the acknowledging press")