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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.