Add form field read-only control and signature interception bridge

[mutumbakato]

Summary

Exposes two native PDF form capabilities through NutrientView, on both the Legacy (Paper) and New (Fabric + TurboModule) architectures, following the BRIDGING.md recipe:

• setFormFieldReadOnly(fullyQualifiedName, readOnly, persist?) — locks/unlocks a single form field. iOS maps persist: true to PSPDFFormField.isReadOnly (persisted PDF flag) and persist: false to isEditable (session-only). Android updates AnnotationFlags.LOCKEDCONTENTS on the field's widget annotations, preserving existing flags (READONLY is ignored for widgets, and Android's FormField has no read-only setter).
• interceptSignatureFields prop + onSignatureFieldTapped event — consumes taps on signature form fields (iOS didTapOnAnnotation: delegate, Android FormManager.OnFormElementClickedListener) and emits {fullyQualifiedName, pageIndex} to JS instead of presenting the native signature UI.
• dismissSignaturePad() — dismisses the native signature creation UI when presented (type-checked against PSPDFSignatureCreationViewController/PSPDFSignatureViewController on iOS; located via ElectronicSignatureFragment.FRAGMENT_TAG on Android), resolving false otherwise. Idempotent.

Also included:

• A Signature Interception Catalog example used as the runtime test harness.
• An implementation guide for customers customizing an SDK fork.

Verification

• npm test (32/32), npm run lint, npm run build-and-generate-types — all pass.
• Catalog Android assembleDebug (compiles legacy + newarch source sets + codegen) and iOS xcodebuild — both succeed.
• Runtime (Maestro-driven, New Architecture) on a Pixel 9 Pro emulator and iPhone 17 Pro simulator:

Test	Android	iOS
Intercept ON: event fires with correct field/page, native UI suppressed	✅	✅
Intercept OFF: default "Add Signature" UI opens unchanged	✅	✅
dismissSignaturePad() with UI open → true, UI closed	✅	✅
dismissSignaturePad() with nothing open → false	✅	—
Lock blocks editor on the target field only; unlock restores	✅	✅

Known caveat surfaced during testing: form interaction (and therefore interception) requires a writable document — Android file:///android_asset/ documents open read-only. Documented in the guide.

Open items before undrafting

• Save-and-reopen persistence assertions; multi-widget fields; rotation during signature UI; same runtime matrix on Paper builds and physical devices.
• Decide whether persist: false should reject on Android instead of behaving persistently.

🤖 Generated with Claude Code

[mutumbakato]

Fix: repeated dismissSignaturePad() failures (69ad436)

Reported behavior: dismiss worked on the first try, then failed on subsequent tries.

Root cause: dismissSignaturePad() only recognized the signature creation UI. Once a signature has been saved to the signature store (or under the legacy signature flow), tapping a signature field presents the saved-signature picker instead — SignaturePickerFragment on Android, PSPDFSignatureSelectorViewController on iOS — which the type checks didn't match, so the call resolved false and left the UI open.

Fix:

• Android: scan candidate fragment managers for instances of both ElectronicSignatureFragment and SignaturePickerFragment (instanceof-based, since the picker's FRAGMENT_TAG is private) and dismiss via the matching static helper.
• iOS: check the entire presented navigation stack against PSPDFSignatureCreationViewController, legacy PSPDFSignatureViewController, and PSPDFSignatureSelectorViewController.

Verified (Maestro, emulator/simulator):

• Android: saved a signature → field tap now opens the "Signatures" picker → dismissSignaturePad() dismisses it and resolves true (previously false/no-op). Creation-UI cycles re-verified on both platforms.
• A signed field opens the annotation context menu (no signature UI); dismiss correctly resolves false and leaves the menu alone.

Guide updated with the expanded targeting and a caveat about the picker/signed-field states.

🤖 Generated with Claude Code