feature: submit-label prop for the return key / IME action

[SRWieZ]

What's wrong

1. The keyboard's submit key can't be configured. On iOS the label is hardcoded — Done when @submit is wired, Return otherwise (NativeUITextInputCore.swift); on Android keyboardOptionsFor never sets an IME action. So a multi-field form can't show the platform Next/Go/Search/Send affordance.

What this does

• Adds an opt-in submit-label prop (next | done | go | search | send | return) to the three text inputs, mapping to SwiftUI SubmitLabel on iOS and Compose ImeAction on Android. Blade takes submit-label or submitLabel; the fluent ->submitLabel() validates and throws on unknown values.
• Moves the filled/outlined Android renderers from KeyboardActions(onDone) to onAny (the bare renderer's existing shape) — with a non-Done IME action, an onDone-only handler would silently drop the @submit dispatch. For the default action the two are equivalent.
• Multiline fields ignore the prop on both platforms: their return key must keep inserting newlines (.submitLabel on a vertical-axis TextField would replace that — same territory as fix(ios): multiline inputs must insert a newline on every keyboard #42).
• Tests: serialization on every variant, all values, both attribute spellings, normalization, unset-not-serialized, invalid throws.

Unset keeps each platform's behaviour byte-for-byte. return is iOS vocabulary (a plain Return key); Android renders its IME default for it. The bare input picks the label up through the shared keyboardOptionsFor as soon as #51 lands (bare doesn't apply keyboard options today).

Before / after (same Blade)

Android emulator, API 36 — the action key goes from the generic checkmark to Next; the numeric field (keyboard="number" submit-label="done") shows the number pad with a Done key:

iOS simulator, iPhone 17 (26.5) — the return key goes from return to next (iOS 26 renders the labels as glyphs):

The "after" builds also carry the follow-up focus-chaining branch; the key face goes through the same resolveImeAction/resolveSubmitLabel path either way.

Happy to PR the matching lines to the text-input docs page once the API is agreed.