The next thing a first run says after the file exists is bare again

Noticed while reviewing [#576](https://github.com/akiomik/nostui/pull/576), which fixes the step before this one. Pre-existing.

## What happens

#576 makes the missing-file error name the directory, the file and the least that goes in it. Follow it, get the contents slightly wrong, and the next message is bare again:

```
Error:
0: missing configuration field "key"
```

Reachable from an ordinary first run in at least three ways:

- the key written under a name that is not `key` — `privatekey` is still accepted and is what older configurations use, so a config copied from an old install or an old README says this;
- the file written as `config.ini` or `config.toml` with the JSON object that the error showed, since those formats do not read it;
- a `config.json` with a typo anywhere in the key's name.

In each case nostui knows the file it read and the field it wanted, and says only the second. `config.ini` is the unkindest: the file parsed, so the user is told their key is missing when what is wrong is the format they chose.

## Why it belongs with #113 rather than inside it

Same first run, different error. #576 is the path where no file exists; this is the path where one does and does not satisfy `try_deserialize`. It comes from `config`'s own `ConfigError::NotFound` rather than from a message this crate writes, so answering it means deciding where to catch that and what to add — the file that was read, at least, and probably that `key` takes an nsec or an npub.

## Acceptance

- A configuration that parses but has no usable key says which file it read.
- A file whose format cannot hold what the user wrote is distinguishable from a key that is genuinely absent.

Start by tracing config's try_deserialize path and how ConfigError::NotFound reaches nostui after a file is read. Compare it with the missing-file path addressed by #576, then determine how a missing usable key differs from an incompatible config.ini or config.toml format. Done means both acceptance cases identify the file and distinguish the failure.

Written by the indexing model from the issue text.