Point Dialog::important_area at the focused button

[hdimer]

Fixes #813.

Dialog::important_area() always returned the content's area, even when a button
had focus - there was a // TODO: if a button is focused, return the button position instead. sitting on that line. So a ScrollView wrapping a tall
Dialog scrolled to the content and stopped, and the buttons below stayed
unreachable once focus moved to them.

Now it matches on self.focus: content focus keeps the existing calculation,
button focus asks the focused button for its important area and translates it by
the offset the button already records. That is the same shape FixedLayout,
LinearLayout and ListView use for their focused child.

The test lays out and draws a 20x5 dialog with two buttons and asserts the
important area for all three focus states. Coordinates are hardcoded rather than
derived from offset/size, so it cannot just restate the implementation - I
checked it fails on master and on the plausible wrong versions (hardcoded button
index; adding borders + padding to the button arm by symmetry with the content
arm).

Two things worth flagging:

• Button offsets are written in draw_buttons(), not in layout(), so before
  the first draw they are still zero. In practice focus only reaches a button
  after an event, and run() refreshes before the first step(), so the offsets
  are current by then; the degenerate case is a scroll to the top for one frame,
  not a panic. It is the same contract check_focus_grab() already relies on for
  mouse hit-testing. Moving the button positioning into layout() would remove
  the hazard, but it duplicates the alignment math and felt like more than this
  fix needed - say the word if you would prefer it.
• This only covers the buttons half of your comment on [BUG] ScrollView on LinearLayout with Dialog doesn't scroll properly #813. The border is still
  excluded from the important area, which is consistent with the content arm but
  means the bottom border row can stay clipped. Happy to include it if that is
  what you want.

cargo fmt, clippy and the full test suite are clean. Two files, theme.rs
and backends/curses/n.rs, are already rustfmt-dirty on master; I left those
alone.

Written with AI assistance; I reproduced the bug, verified the fix and ran the
tests myself.

[gyscos]

Hi, and thanks for the work! Looks good!