AdminTool: Enter saves and Esc cancels in the New Item and New Robot dialogs

[meketreve]

Enter now saves and Esc now cancels in the New Item and New Robot dialogs of the AdminTool.

Where this came from, since it explains the scope

The original idea was for the game client: make Enter activate the OK/Confirm button in popups that
already open with their text field focused — the Shift-drag stack-split dialog is the obvious case,
where you type the quantity and then still have to reach for the mouse.

That is not something this repository can do, and the new client is in progress and not shareable, so
the idea is parked until it is. This pull request is the same idea applied where it is reachable, and
it was deliberately used as a small exercise: pick a bounded change, in an area with an existing
pattern to copy, and see whether it can be made without breaking anything around it.

It stands on its own regardless of that origin. Sixteen AdminTool dialogs already pair IsDefault on
their confirm button with IsCancel on Cancel. These two were the only exceptions: Enter did nothing
and Esc did nothing, in the two largest data-entry dialogs in the tool. So this is quality of life, and
it removes an inconsistency rather than introducing a new convention.

The part worth reviewing

IsDefault="True" on its own would have been a regression, which is why this is four files instead of
two attributes.

Enter activates the default button without moving focus. A TextBox bound with WPF's default
UpdateSourceTrigger=LostFocus is therefore still holding an uncommitted value when SaveCommand
runs. Roughly fifteen fields across these two dialogs are bound that way — Mass, Volume, Health
and Quantity among them; only DefinitionName, CategoryFlags, AttributeFlags and
DescriptionToken use PropertyChanged.

Measured rather than argued. With the hook removed, typing 555 into Mass and pressing Enter
generated:

INSERT INTO entitydefaults (..., mass, ...) VALUES (..., 0, ...)

With the hook in place, the typed value reaches the generated SQL. So without the PreviewKeyDown
handler, adding the shortcut would have silently written blank fields — worse than having no shortcut.

The handler pushes the focused single-line TextBox to its source before the key propagates.
Multi-line boxes are skipped explicitly: they consume Enter themselves, so the Note field still inserts
a newline.

IsCancel was the other thing checked rather than assumed. CancelCommand already closes the dialog
through CloseRequested, so IsCancel adds a second path. That is not new: the existing sixteen
dialogs all pair IsCancel="True" with a Click handler that sets DialogResult = false, so the same
double set is already in production and works.

Validation

No test tier covers the AdminTool, so this was verified by hand against a local database with the
session in SQL-script mode, which writes a file instead of touching the database:

• Enter saves, and the value typed last reaches the generated SQL
• Enter with the handler removed produces mass = 0 — the regression observed failing, per the
  repository's own rule
• Esc closes without saving
• Enter inserts a newline in the multi-line Note box rather than saving
• Enter still commits a DataGrid cell and moves down rather than saving the item — this one mattered,
  since the handler runs on the window's PreviewKeyDown, before the grid sees the key

Solution builds clean; the unit and integration tiers and the smoke script were run and are unaffected,
as none of them reach the AdminTool.

One question

If you would rather the two dialogs matched the other sixteen exactly — Click handlers instead of
Command bindings — say so and I will convert them. I left the MVVM shape alone because changing it
would be a larger diff than the behaviour being added.