PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#running-unit-tests-application.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

What is the current behavior?

#11216 consolidated padding application into an internal paddingInternal property and deleted the per-side [padding*Property.setNative] / [padding*Property.getDefault] handlers from Button (iOS + Android), Label (iOS), LayoutBase (Android), TextBase (Android), TextField (iOS) and TextView (iOS).

Those per-property native handlers are the de-facto public extension surface every plugin builds on. Two breakages for subclasses (e.g. @nativescript-community/ui-label):

1. Crash — an override that chains to the base implementation now throws, because the base handler no longer exists:

   [paddingTopProperty.setNative](value) {
       if (!this.isUsingNSTextView) {
           super[paddingTopProperty.setNative](value); // TypeError: … is not a function
       }
   }

   TypeError: (intermediate value)[paddingLeftProperty.setNative] is not a function
       at applyAllNativeSetters (ui/core/properties/index.js)
       at initNativeView …
   

2. Silent bypass — an override whose purpose is to suppress core's padding application no longer suppresses anything: core applies padding through paddingInternal, around the per-side protocol.

What is the new behavior?

The per-side handlers are restored on all six classes, restructured so #11216's one-native-write goal still holds:

• Each [padding*Property.setNative] stages its side into a pending insets struct (using the same effective-value computations the consolidated handler used).
• [paddingInternalProperty.setNative] seeds the struct from the current native padding, drives the four per-side handlers — subclass overrides included — and commits a single native write.
• A side whose override does not chain to super keeps its current native value, which is exactly what suppression produced before perf(core): reduce padding native setter calls #11216.
• getDefault handlers return the same values they did before.
• Standalone invocations of a per-side handler are no-ops; every padding change also updates paddingInternal, which performs the flush.

So: super[padding*Property.setNative] resolves again (no crash), override semantics work again, and padding is still applied in one native call per update.

New regression spec (padding-native-protocol.spec.ts): asserts the handlers exist on the affected prototypes and exercises the exact plugin pattern — a subclass handler chaining to super — without throwing. 426 unit tests passing, core:build clean for both platforms.

Update (d333b1821): the consolidated write now stands down entirely when a subclass overrides any per-side handler (detected once per constructor). In that case the property machinery drives the per-side handlers directly, each applying its own side — full pre-#11216 semantics:

• suppress: an override that doesn't chain to super means core never touches the native padding for that side (not even a rewrite of the current value — important when the plugin redirects padding to a different native mechanism);
• transform: super[padding*Property.setNative](differentValue) applies the transformed value on Android, which honors the value argument again exactly like the old handlers (iOS handlers keep reading effective values, as they always did);
• chain: plain super chaining applies the side normally.

Views with no overrides keep the staged single-native-write path. The spec now covers all of the above against a stubbed native view.