[RNE Rewrite] chore!: miscellaneous jsdoc, export improvements and small fixes

[barhanc]

Description

Refactor the public API surface, add package subpath exports for domain-specific imports, and standardize TSDoc documentation across all modules in preparation for documentation rewrite.

Package Subpaths

Add subpath exports in package.json for cv, llm, nlp, speech, math, and schema, enabling:

import { ... } from 'react-native-executorch/cv';
import { ... } from 'react-native-executorch/llm';

Add corresponding tsconfig.json path aliases for all example apps.

API Changes

• Flatten exports: remove re-export leaks, flatten CV operations into cv namespace
• Rename ops: ops/boxes → ops/box, ops/points → ops/point (singular consistency)
• Move preprocessing: preprocessing → cv/utils/imagePreprocessor
• Export constants directly: export * from './constants' instead of export * as constants
• Namespace types under domain modules: app imports now use llm.LLMGenerationStats, nlp.PiiEntity, schema.ConcreteDim, etc.
• Model registry: models with variants now use .DEFAULT accessor (e.g., models.objectDetection.SSDLITE320_MOBILENET_V3_LARGE.DEFAULT)

Documentation

• Add @packageDocumentation and @category tags to all modules
• Standardize TSDoc annotations (error throws, tensor shapes/dtypes, worklet threading)
• Add module-level docs to index.ts, models.ts, constants.ts, utils.ts
• Link imperative APIs and types in hook JSDoc

Hooks

• Use switch statement for TTS factory resolution in useTextToSpeech
• Format JSDoc type links onto dedicated lines to prevent Prettier wrapping
• Use undefined for absent state instead of null

Core

• Return raw ConcreteDim for untyped dim accessors
• Mark getRegisteredBackends as worklet

Implementation

• math.ts: Extract RandomNormalOptions type; use Math.random() instead of Date.now() for seed default
• schema.ts: Extract resolveSymbolDim and createSpecMatch helpers from validateSpec to reduce duplication and improve readability

Introduces a breaking change?

• Yes
• No

Type of change

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Documentation update (improves or adds clarity to existing documentation)
• Other (chores, tests, code style improvements etc.)

Tested on

• iOS
• Android

Testing instructions

• Rebuild all example apps to make sure nothing is broken

Screenshots

Related issues

Closes #1380

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes generate no new warnings

Additional notes

[msluszniak]

I'm wondering how do we want to communicate the fact that default model variant is probably rarely the optimal one? I think that our default behaviour will be including all backends etc. and if you want to exclude them, you need to do it manually. This way we would be able to set default models per platform which guarantees the best performance. Otherwise, I think that many people can miss huge advantage from backend acceleration.

[barhanc]

I'm wondering how do we want to communicate the fact that default model variant is probably rarely the optimal one? I think that our default behaviour will be including all backends etc. and if you want to exclude them, you need to do it manually. This way we would be able to set default models per platform which guarantees the best performance. Otherwise, I think that many people can miss huge advantage from backend acceleration.

Agreed. This will require changes in the download scripts and opt-in logic, right?

[msluszniak]

I'm wondering how do we want to communicate the fact that default model variant is probably rarely the optimal one? I think that our default behaviour will be including all backends etc. and if you want to exclude them, you need to do it manually. This way we would be able to set default models per platform which guarantees the best performance. Otherwise, I think that many people can miss huge advantage from backend acceleration.

Agreed. This will require changes in the download scripts and opt-in logic, right?

I need to double check before any changes in the model registry regarding changed defaulting behaviour.

[msluszniak]

Four consistency gaps found while reviewing this branch.

1. Agent skills still document the old API. .agents/skills/add-task-pipeline/SKILL.md:103 imports from './preprocessing' (now ../utils/imagePreprocessor), and .agents/skills/model-schema-validation/SKILL.md uses constr / constr.eq in 9 places.

2. Eight @category values are missing from categoryOrder in docs/typedoc.json: CV / Functions, Core / Schema / Functions, Core / Schema / Types, LLM / Functions, Math / Functions, Math / Types, NLP / Functions, Speech / Functions. They land in the trailing * bucket, so X / Types renders above X / Functions on the cv/llm/nlp/speech pages while math and schema render the opposite way. Deriving this list and VALID_CATEGORIES in .eslintrc.js from one source would stop them drifting again.

3. .DEFAULT is not applied to the deepest variant groups. 74 groups have it, 33 do not: every YOLO26.*.SIZE_384/512/640 under objectDetection and instanceSegmentation, plus YOLO26_POSE.SIZE_*. YOLO26.NANO.DEFAULT works, but YOLO26.NANO.SIZE_512 still requires .XNNPACK_FP32.

4. Two new typedoc warnings (three others are fixed by this PR): Failed to resolve link to "Tokenizer" in createTokenizer, since Tokenizer is not imported in tokenization.ts; and TtsHookResult is no longer exported, so useTextToSpeech's return type drops out of the API reference.

[msluszniak]

Do we want to add the target default value mechanism in this PR or in a separate one?

[msluszniak]

Tested all apps and besides one comment with some nits everything look cool.