`value` preserves the textarea's trailing newline, breaking consumers that split on `\n`

Problem/Motivation

When a key is entered via the textarea widget and the user presses Enter at the end of the input (or pastes from a source that already ends in \n), the trailing newline is stored verbatim in the value column. Leading whitespace (e.g. an accidental indent on paste) is similarly preserved.

For most callers this is invisible — Drupal\sshkey\Utils::initialize() splits on ' ', so the trailing \n just becomes a tail of the comment field, which nothing else inspects. But any consumer that builds a multi-key blob by joining multiple values with \n (e.g. to materialize an authorized_keys file) gets a phantom line where one key's tail and the next key's header sit on the same string before implode. When the downstream parser splits on \n, it sees a malformed line.

Concrete case: ansible.posix.authorized_key rejects the phantom line with "invalid key specified: <fragment>", so the entire deploy fails.

Steps to reproduce

1. Apply a sshkey field to a fieldable entity.
2. Edit an entity, paste a valid SSH public key into the textarea widget, press Enter once at the end, save.
3. Reload the entity and inspect the stored value — it has a trailing \n. (Optionally: load multiple such items, implode("\n", ...) them, feed the result to ssh-keygen -lf - or ansible.posix.authorized_key; the parser blows up on the phantom line.)

Proposed resolution

Trim leading/trailing whitespace from value inside SshKeyItem::onChange() before fingerprint and name derivation, and write the trimmed value back via writePropertyValue() so the stored row is clean. This fixes the bug for every entry point — widget, programmatic setValue(), JSON:API, migration — not just the textarea widget.

Remaining tasks

• Trim in onChange() before downstream property derivation.
• Kernel-test coverage for both trailing-newline and leading-whitespace cases (testOnChangeValueTrimsWhitespace).
• Maintainer review.
• Tag a release.

API changes

None. value is still a string; it just no longer carries surrounding whitespace.

Data model changes

None at the schema level. Existing rows that already have trailing whitespace will normalize on their next save; an hook_update_N() mass-rewrite is possible but probably not worth the migration overhead — the bug only surfaces in callers that \n-join multiple values, and those callers can defensively trim too.