What stops a deep import once Metro will not?

[diegolmello]

Part of #301

Question

Measured on #303: an exports map cannot enforce the public surface in the app's bundle. Metro reads the map, warns that a subpath is not listed, then falls back to file-based resolution. metro-resolver's resolvePackage() catches the not-exported error, logs, and falls through unconditionally — there is no strict option.

So the map enforces for Node, tsc and Jest, and merely advises for Metro. If "index.ts is the only path a consumer can resolve" is to hold as stated on #301, something in CI has to fail on a deep import, because a warning cannot.

The obvious shape is a lint rule in Rocket.Chat.ReactNative — an ESLint no-restricted-imports pattern on @rocket.chat/sdk/*, at error, enforced in CI.

What is worth settling:

• Does the rule earn its keep? What belongs in the public surface, and does the DDP driver? #304 moves the app's only two deep-importing files into this repo, so on the day this lands the app has zero deep imports. The rule guards against future regressions, not a present breakage.
• Does it belong in the app, in this repo, or both? The app is where the imports are written; this repo is where the surface is defined.
• require or import? Both existing deep imports used require, which is exactly the form tsc does not see — so the rule has to catch call expressions, not just import statements.
• Error or warning, and does it block CI?

Ordering across the two repos is #305's decision, not this one's.