Auto-ids per type not per group; show detected_id in proposal UI

Auto-assignment (Board.add_target/add_ally with no explicit id_) now
scopes its 1/2/3... sequence per TYPE within each group, not one
sequence shared across every type in the group -- Tank#1/Infantry#1
rather than Tank#A/Infantry#B, matching the game's own numbering.
Reverses the type-scoping half of an earlier fix in this file (see
TODO.md's "Allies and enemies seem to share indices" entry) per
explicit user direction; the targets-vs-allies namespace split that
fix also made is untouched, still correct. _next_free_id (letters,
rolling over to "AA" past 26) is replaced by _next_free_numeric_id --
a plain counter can't run out the way a fixed alphabet could, so
there's no equivalent rollover concern. test_models.py updated to
match (one test asserts the opposite of before, renamed accordingly).

detected_id (map_vision.read_marker_id) was being logged but never
shown anywhere a human could actually check it against the
screenshot before now: added to the proposal popover's heading and
the pending-proposal's own on-map label.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

TODO.md

@@ -198,3 +198,33 @@ Status legend: [x] fixed+tested, [~] partially addressed, [ ] open/needs input
       code exists in this repo at all yet, real scope work (find/access
       the game's log, agree a "<Type>#<id> Destroyed" grammar, wire it
       into a dedup key) rather than a quick pass.
+
+      Follow-ups from user feedback after the above landed:
+      - `_accept_proposal` now actually USES `detected_id` (it was only
+        being logged before, never applied) -- an accepted proposal's
+        entity id prefers the detected number over auto-assignment,
+        falling back on a collision. 4 new regression tests
+        (`tests/test_app_accept_proposal.py`).
+      - Auto-assignment itself (`Board.add_target`/`add_ally` with no
+        `id_`/no usable detection) changed from one shared letter
+        sequence per group (targets, or allies) to its own 1/2/3...
+        sequence per TYPE within each group -- Tank#1/Infantry#1 rather
+        than Tank#A/Infantry#B, matching the game's own numbering (and
+        what `detected_id` looks like when it IS read). This directly
+        reverses an earlier deliberate fix in this same file (see the
+        "Allies and enemies seem to share indices" entry above, which
+        moved FROM per-type TO shared-per-group) -- that fix is still
+        correct for what it fixed (targets-vs-allies must stay separate
+        namespaces), just not for per-type-vs-shared, which the user has
+        now clarified the other way. `_next_free_id` (the letter
+        sequence, with its own StopIteration-safe rollover to "AA" past
+        26) is gone, replaced by `_next_free_numeric_id` -- a plain
+        counter can't run out the way a fixed alphabet could, so there's
+        no equivalent rollover concern to carry forward. Tests in
+        `test_models.py` updated to match (renamed
+        `test_auto_id_is_shared_across_types...` ->
+        `test_auto_id_is_per_type...`, since it now asserts the opposite).
+      - `detected_id` is now shown, not just logged: the proposal
+        popover's heading (", id #8") and the pending-proposal's own
+        on-map label (`? #8 G8 5:4`) both show it while there's still a
+        screenshot up to check it against by eye.