feat: highlight a transaction row while targeting it — red for delete, green for edit

[obeidahmad]

Problem / motivation

When deleting or editing a transaction by its #, nothing in the table shows which row is targeted. The user types tx del 3 / tx edit 3 amount 50 and has to trust the number is right — there's no visual confirmation of the row before the action lands.

Two facts shape the fix:

• tx del is a confirm command (monay/app/commands/specs.py:68, confirm=True), so it has a Yes/No step; the pending command is held in self._pending (monay/tui/app.py:54).
• tx edit is not confirmed (monay/app/commands/specs.py:58) — it applies immediately — so its only chance to highlight is while the command is being typed.
• The command bar currently has no live-change handling; the app only reacts on submit (on_input_submitted, monay/tui/app.py:74). The plain Input (monay/tui/command_bar.py:14) does emit Input.Changed, but nothing consumes it yet.

Proposed solution

Highlight the whole targeted transaction row in the Transactions table, colored by intent:

• delete → red, edit → green.

And do it in both windows the user is "aiming" at a row:

1. While typing the command — as the user types tx del <n> or tx edit <n> …, live-parse the partial input and highlight row <n> (red for del, green for edit). Clears when the text no longer targets a row.
2. During the Yes/No question (delete only) — keep the red highlight on <n> while the confirmation is pending (self._pending).

Sketch:

1. Add an Input.Changed handler on the app that inspects the current command-bar text; if it parses to tx del <n> or tx edit <n> …, derive (<n>, "red"|"green"). Parsing must tolerate incomplete input (the user is mid-type), so a lightweight prefix parse rather than the strict registry parser.
2. Also derive the same target from self._pending for the pending-delete case.
3. Thread the target into the renderer: _content_renderable already calls render_transactions(month, s.tx_filter, s.currency) (monay/tui/app.py:151); add a highlight=(<n>, color) argument, and in the row loop (monay/tui/screens/transactions.py:43, # is the enumerate index at :28) style the matching row.
4. Re-render the content on each relevant keystroke while on the Transactions tab; reset when the text clears, the tab changes, or the command resolves.

The <n> is the shown #, so this stays consistent with however the table is ordered (note #29 changes that ordering).

Alternatives considered

• Highlight only during the Yes/No confirmation (the original scope of this issue) — rejected: that misses tx edit entirely (it has no confirmation) and gives no feedback while the number is still being typed, which is exactly when a wrong # does damage.
• A marker glyph in the # column — rejected: item 13 asks for the whole row to light up; a full-row red/green read is harder to miss.
• Text prompt naming the field/amount — rejected: with many rows it's still easy to mis-map; coloring the actual row is unambiguous.