fix(options): edit apps one row per step in a multiline field, and report discovery

The live Apps page showed the whole map as ONE long line with nowhere to add a
row. Cause: the field was a bare `vol.Optional(...): str`, and HA renders a
selector-less string as a SINGLE-LINE input (pre-fix wire field:
{"type": "string", "name": "app_name_map"} — no selector key). It is a
multiline TextSelector now: the real-HA test pins
selector.text.multiline on the wire and an N-line save/reopen round trip.

HA has no table selector, so the Apps sub-screen is a menu of row actions
(whole list as text / add / edit / remove) instead of one form:

- the EDIT row lists every app the user can act on: the rows they saved AND the
  apps discovery found, marked `[detected]`, each labelled "name (package id)"
  or "package id (no name yet)" — the user's Shield exposes no device labels at
  all, so the unnamed case is the common one and it must not read as its own id
  twice, and picking it is how a name gets set (saving stores the row)
- add: package + name + optional icon, refused by the SAME `_valid_app_row`
  rule the text field uses, with an error on the page
- edit: PREFILLED from the stored row (suggested values — a voluptuous
  `default=` never reaches the browser, so the form would have opened blank);
  the device's mdi: icon is never prefilled into the icon column
- remove: pick a SAVED row, then an explicit confirmation menu; cancelling
  keeps it (a detected app has no line to delete)
- edit/remove rows are offered only while something is stored
- every mutation writes ONE row through `_write_app_row`/`_drop_app_row`, so
  untouched rows and their icons stay byte-for-byte as they were

The Discover row was a silent no-op ("seems to load then do nothing"): it now
returns a one-line verdict the menu shows — N apps found / the Shield reported
none / the sweep could not reach the Shield / ADB is not set up — while still
never raising and never caching a failed sweep as an answer.

Also fixes `async_step_menu_again`, which the real FlowManager dispatches with
user_input and which raised TypeError for every menu offering that row (only
reachable through a stub before, hence unnoticed).

Docs: README and BOTH strings files (byte-identical) describe the editor, the
one-per-line format, the detected-app dropdown and the four Discover verdicts.

README.md

@@ -312,7 +312,7 @@ and only **Save and close** commits:
 | --- | --- |
 | **Main setup** | Shield address, ADB port, `Read state over ADB`, `Add the Nvidia Remote Protocol`, `Show title and artist`, `Allow the adb_command action`, Jellyfin player, power switch |
 | **Receiver** | the receiver/soundbar entity and the input it uses |
-| **Apps** | the apps table — one row per app (see below) |
+| **Apps** | the apps editor — add, edit or remove one app, or paste the whole list (see below) |
 | **Scripts** | one optional script per command, plus the remote-entity script, the channel digit delay and send-ENTER |
 | **Save and close** | writes the merged options and reloads the integration |
 
@@ -331,7 +331,29 @@ the menu's description names what is still to pair.
 
 ### The Apps table
 
-The **Apps** row is an editable table. One app per line, in the documented format:
+The **Apps** row opens a small editor rather than one long form. Home Assistant has no
+*table* selector, so a table is edited the way HA edits one — **one row per step**:
+
+| Row | What it does |
+| --- | --- |
+| **Edit the whole list as text** | the multiline field below: paste, rename or delete rows in one go |
+| **Add an app** | package id, name to show, and an optional icon |
+| **Edit an app** | pick one of the apps the Shield reported, or one you saved; its name and icon open prefilled |
+| **Remove an app** | pick a saved row, then confirm it on the next step |
+| **Back to the main menu** | leave the editor (nothing is written until **Save and close**) |
+
+*Edit* and *Remove* are offered only while there is something to act on: a table with
+no remembered rows and no discovery yet shows just the text field and *Add an app*. The
+editor's description lists every app it knows — the rows you saved, and the ones
+discovery found, marked `[detected]`. **Edit** acts on both (that is the point: the
+Shield exposes no app labels of its own, so a detected app reads as `name (package id)`
+or as `package id (no name yet)`, and picking it is how you give it a name — saving
+stores it as one of your own rows). **Remove** acts only on rows you saved, because a
+detected app has no line to delete (it would simply come back with the next sweep).
+Removing a row never uninstalls anything from the Shield — the app simply stops being
+offered. Rows you do not touch are left exactly as they were.
+
+The text field is one app per line, in the same format the integration stores:
 
 ```
 ar.tvplayer.tv=TiviMate
@@ -340,16 +362,14 @@ com.netflix.ninja=Netflix
 ```
 
 `package=name` is enough; an optional `|icon` after the name adds a picture (a URL, or
-a `camera.*` entity id — see *Sources* below). The field always opens carrying the
-current rows, so adding, renaming or deleting an app is an edit to that text:
-
-- **add a row** — type a new line
-- **edit a row** — change its name, icon or package id
-- **remove a row** — delete its line
+a `camera.*` entity id — see *Sources* below). The field opens carrying the current
+rows, and it is a **multiline** input: earlier versions rendered it as a single-line
+string, so the whole table arrived as one flattened line with nowhere to add a row.
 
 A blank field clears the table (and the integration falls back to its built-in app
-list). A malformed row — no `=`, or an empty name — is rejected with an error on the
-page rather than being half-saved.
+list). A malformed row — no `=`, an empty name, a space in the package id or in the
+icon — is rejected with an error on the page rather than being half-saved, and the
+*Add* and *Edit* forms enforce exactly the same rule.
 
 A receiver may be a **`switch.*`** as well as a `media_player.*`: a soundbar or
 speaker that only knows on and off is a valid receiver. Playback then **ensures
@@ -442,8 +462,10 @@ outcome that leaves you guessing.
 ### App discovery (what is actually installed)
 
 The Configure page can ask the Shield which apps it has, so the **Apps** table does not
-start from a four-entry guess. Pick **Discover installed apps** on the Configure menu
-and the table is rebuilt from two ADB queries:
+start from a four-entry guess. Pick **Discover installed apps** on the Configure menu and
+the table is rebuilt from two ADB queries — and the row then **says what happened** (see
+*What the Discover row tells you* below), because an action that appears to do nothing is
+indistinguishable from a broken integration:
 
 | Command | What it returns | How it is treated |
 | --- | --- | --- |
@@ -486,6 +508,21 @@ the menu says why. A sweep that **could not run** is not cached as an answer: it
 recorded as `unknown` and retried, so a Shield that was asleep at startup is picked up
 by the next refresh instead of reporting an empty device for six hours.
 
+#### What the Discover row tells you
+
+The Discover row is an *action*: it runs a sweep and returns you to the same menu with a
+one-line verdict, which replaces the usual "not discovered yet" note:
+
+| Verdict | What it means |
+| --- | --- |
+| `N apps found on the Shield — the table is updated.` | the sweep ran, and the editor's text field now carries the discovered rows |
+| `the Shield reported no installed apps — the table keeps your saved rows.` | the sweep ran and found nothing to add; your rows are untouched |
+| `the discovery sweep could not reach the Shield — check the ADB connection; your saved rows are unchanged.` | the sweep failed; nothing was cached as a result and nothing you wrote was lost |
+| `ADB is not set up for this entry — nothing could be discovered.` | this entry has no ADB manager (a remote-protocol-only setup), so there is nothing to sweep |
+
+The action is best-effort by design: whatever the verdict, the Configure menu still opens
+and the editor still works on the rows you wrote.
+
 **For dashboards** the same table is a sensor: `sensor.<name>_installed_apps`, whose
 state is the app **count** and whose `installed_apps` attribute is the list of
 `{package, name, icon}`. Its `discovery` attribute says `ok`, `pending`, `unknown`,