fix(jans-cli-tui): preserve the per-RP FIDO2 policy when editing a relying party

**Describe the bug**

Sub-issue of #14516, and filed as a bug rather than a feature because of what the save path does.

`jans-cli-tui/cli_tui/plugins/020_fido/main.py:294` rebuilds each relying party from scratch on save, from
only the two columns the table holds:

```python
fido2_static['rp'] = []
for name, domains in self.requested_parties_container.data:
fido2_static['rp'].append({'id': name, 'origins': domains.splitlines()})

The table itself is built from the same two fields (:153, headers ['id', 'origins'] at :157). So once
RequestedParty carries a policy, an administrator who opens the FIDO2 screen and saves — even without
touching the relying parties — silently discards the policy of every RP. Nothing warns, and the loss is
only visible later as attestation behaviour quietly reverting to the global mode.

This is a data-loss path, not a missing feature. It is worth landing close behind the model change rather
than being left as follow-up polish.

To Reproduce

1. Configure an RP with a policy (for example attestationMode: enforced), by Config-API or directly.
2. Open jans-cli-tui, go to the FIDO2 plugin, and save without editing anything.
3. Read the configuration back.

Observed behavior

The RP's policy is gone. Its attestationMode silently falls back to the global value.

Expected behavior

Editing or saving preserves any part of a relying party the screen does not manage, and the policy is
viewable and editable alongside the existing id and origins.

Describe the solution you'd like

Two parts, and the first matters more:

1. Stop discarding unknown fields. Carry the original RP objects and update them, rather than
reconstructing {'id': ..., 'origins': ...}. That also makes the screen robust against the next field
added to the model — of which #14516 lists several.
2. Add the policy to the RP dialog so it can be edited. The dialog already reads its field help from the
published schema —
get_schema_from_reference('Fido2', '#/components/schemas/RequestedParty') at :52, used via
get_help_from_schema(...) at :55 — so the swagger from the Config-API sub-issue supplies the help
text for free, provided that lands first.

Additional context

Depends on the model sub-issue, and on the Config-API sub-issue for the schema-driven help. Part 1 is worth
doing even if part 2 is deferred, since it is what prevents the data loss.