docs(jans-config-api): add the per-RP FIDO2 policy to the fido2-plugin swagger

**Is your feature request related to a problem? Please describe.**

Sub-issue of #14516, which lists the Config-API plugin and its swagger among the surfaces that must carry
the per-RP policy.

Checking what the plugin actually does narrows this considerably. `Fido2ConfigResource` does not map fields
individually — `getFido2Configuration()` returns the whole `AppConfiguration` and
`updateFido2Configuration()` takes the whole object and merges it:

```java
public Response getFido2Configuration() {
AppConfiguration appConfiguration = this.fido2Service.find();
return Response.ok(appConfiguration).build();
}

So once RequestedParty carries a policy field, the REST API serialises and accepts it through Jackson
with no resource or service change. The endpoint is already there: @GET and @PUT on
Constants.FIDO2_CONFIG.

What does not follow automatically is the swagger, which is hand-maintained. Today
jans-config-api/plugins/docs/fido2-plugin-swagger.yaml:1732 declares:

RequestedParty:
type: object
properties:
id:
type: string
origins:
type: array
items:
type: string

Left alone it silently drifts: the API accepts and returns a field its own published contract does not
document, so a client generated from the spec drops it.

Describe the solution you'd like

- Add the policy object to the RequestedParty schema in fido2-plugin-swagger.yaml, mirroring the
model, with the same "unset falls back to the global value" wording used on the model field.
- A round-trip test: PUT a configuration whose RP carries a policy, GET it back, and assert the policy
survives — that is the thing that would otherwise regress unnoticed, since nothing else exercises it.

Describe alternatives you've considered

- Rely on Jackson and skip the swagger. Rejected: the spec is the published contract, generated clients are
built from it, and it is also what drives the CLI-TUI help text (see the CLI-TUI sub-issue), so the drift
propagates.

Additional context

Depends on the model sub-issue. An RP with no policy must serialise exactly as it does today, so existing
API clients are unaffected. Smaller than it first appears — schema plus a test, not plugin code.