feat: support renamed plugin settings and secrets during upgrades

[catherineluse]

Context

Plugin configuration carry-over currently matches settings and secrets by exact key. Intentional key renames are therefore treated as a dropped old field plus a new unset field.

Follow-up from the completed plugin configuration UX and integrity design (#164 and gennit-project/multiforum-nuxt#392).

Proposed behavior

• Define a manifest-level renamedFrom convention for settings and secrets.
• Carry a setting value only when the target field explicitly names the old key and the value remains valid for the target schema.
• Re-point a stored ServerSecret only for an explicit compatible rename; never expose or decrypt its value.
• Detect ambiguous mappings, collisions, and rename chains and fail safely.
• Report renamed fields distinctly in the upgrade carry-over report and expose enough metadata for the frontend preview.

Acceptance criteria

• Pure reconciliation tests cover compatible setting renames, invalid values, collisions, and absent source keys.
• Secret migration tests verify the node is re-keyed without reading plaintext.
• Existing exact-key carry-over behavior remains unchanged when renamedFrom is absent.
• Manifest/type documentation describes when a rename is safe versus when a new key should be required.