Add generic form-field editing support

Espera al Issue #84 y, después, empieza leyendo su field/widget model público, el naming y las decisiones de compatibilidad. Usa esas decisiones para definir el comportamiento compartido del editor y la API pública, con pruebas de nivel unitario y de navegador que cubran múltiples widgets, propiedades de fields y widgets separadas, y overlays genéricos. Se considera terminado cuando la base sea reutilizable sin implementar tipos de field individuales ni workflows de PDF/signing.

This issue tracks the next editor-level step for form fields in pdf-elements.

The goal is to add generic form-field editing behavior after the public field/widget model is defined.

This issue is blocked by #84. The implementation details and final scope must follow the data model, naming and compatibility decisions made there.

Expected direction

After #84 is completed, this issue should provide the common editor behavior needed by future field types, such as:

• create and place a field widget;
• select a field or widget;
• move and resize widgets;
• edit shared field properties;
• edit widget-specific properties;
• support values, required/read-only state and options where applicable;
• keep one logical field connected to one or more widgets;
• expose behavior through the public API without depending on internal Vue state.

The implementation should remain generic to a Vue 3 PDF editor and must not introduce LibreSign or Nextcloud workflow concepts.

Out of scope

Do not use this issue to implement every field type.

Specific behavior for text fields, checkboxes, radio groups, dropdowns and other controls should be added only after the generic editing foundation is stable.

PDF AcroForm parsing, PDF writing and signing are also outside the scope of this package.

Acceptance criteria

The final acceptance criteria should be refined after #84 is completed.

At minimum, the implementation should:

• follow the public field/widget model defined in #84;
• provide common editing behavior that can be reused by different field types;
• support multiple widgets for the same logical field;
• keep field-level and widget-level properties clearly separated;
• remain compatible with generic non-form overlay use cases;
• include unit and browser-level tests for the shared behavior;
• avoid LibreSign- or Nextcloud-specific domain concepts.

Dependency

Blocked by #84.

Do not start implementation until the model and public API decisions from #84 are available.

Additional context

• If you have questions, feel free to ask in this issue.
• Give a ⭐️ to pdf-elements if you find the package useful.
• You can also support the project by giving a ⭐️ to LibreSign.