TextInput: native search semantics, input length constraints, and keyboard hints

## User need

I would like to use published TextInput controls for search and exact-value grid editors without copying the component or casting unsupported props.

At `47ba5526fa93f2bbcb7c0c26ab0a49d86cf37825`, TextInput already renders a native input and forwards remaining props, but its public contract accepts only text/password/email, does not declare maxLength, and inherits a BaseProps omission of inputMode.

## Proposed caller-owned distinctions

- **Search semantics:** the same string may be an ordinary editable value or a search query. The caller knows which; a label is not reliable runtime metadata. Propose `type="search"` alongside the existing types.
- **Native input-length constraint:** otherwise identical text fields may have different accepted storage or exchange limits. Propose an optional native length attribute, with no silent truncation of caller-supplied controlled values and no counter or custom validation engine.
- **Keyboard hint without coercion:** an exact decimal editor and an unrestricted text editor may both hold strings, but need different virtual-keyboard hints. Propose the native inputMode union. For example, `9007199254740993.01` must remain an exact string, not become a JavaScript number.

Defaults and the controlled string/onChange contract would remain unchanged.

## Decision requested

Would the owners accept these three native capabilities on TextInput? In particular, should native length enforcement use `maxLength`, or a distinct native-attribute name to avoid confusion with TextArea's soft character counter?

I am deliberately not proposing a counter, new Field footer layout, numeric parsing, or changes to NumberInput. Related work found during the overlap search: #4233 concerns shared counter/status layout; #4186 concerns NumberInput's numeric editing model; #4018 concerns OTP input. None appears to own this exact TextInput proposal.

The current public-component API / AST-002 / knowledge-contracts guidance requires an owner decision recorded in the canonical semantic contract before acceptance. I am asking for that direction, not treating a successful prototype as API approval. The separate input-event-target typing correction can remain a narrow independent fix.

## Local evidence, not publication readiness

Each proposed addition first failed core TypeScript checking at a public JSX/type use and then passed after its declaration was added. The prototype reuses existing native prop forwarding rather than adding runtime machinery.

- Core type checking, consumer-doc type checking, and 106 focused TextInput/doc tests pass.
- A real Chromium Storybook test verifies the named searchbox, native 32-unit typing limit, and keyboard Clear restoring input focus.
- Fresh Storybook and core builds pass, including emitted declarations and CSS checks.
- Local implementation reviews found no runtime defect; API-owner acceptance remains outstanding.
- Repository-wide validation is not claimed green: the full run is still being reconciled, including unrelated macOS fixture and timing failures.

No implementation PR has been opened for these additions yet.