Document Fantom convention: prefer testing through the public API

Summary:
Adds a convention to the Fantom README recommending that tests exercise React Native through its public API (importing from `react-native`) whenever possible, rather than reaching into internal modules. Exercising the public surface also drives the underlying native (Fabric/TurboModules) code, so tests stay close to real usage and are more resilient to internal refactors.

Changelog:
[Internal]

Differential Revision: D110918650

Author: rubennorte

private/react-native-fantom/__docs__/README.md

@@ -180,6 +180,19 @@ hi
 
 ### Conventions
 
+- Prefer testing React Native through its public API (import from
+  `'react-native'`) whenever possible, rather than reaching into internal
+  modules or relying on private/protected members (e.g. `__`-prefixed methods
+  and fields such as `__getValue()`). Exercising the public API also drives the
+  underlying native (Fabric/TurboModules) code, so tests stay close to real
+  usage and are more resilient to internal refactors. Observe results through
+  the public surface too — e.g. assert the rendered output
+  (`root.getRenderedOutput(...)`) or values delivered to public listeners
+  rather than reading private state.
+  - When Fantom doesn't support something (a native module, a capability, a way
+    to observe a result, etc.), it's fine to reach into internals to work around
+    that limitation. Prefer a short comment explaining why the internal access is
+    necessary.
 - Place test files in `__tests__` directories alongside the code being tested.
 - Benchmark tests use the `-benchmark-itest.js` suffix.
 - Use `Fantom.runTask()` to render and run synchronous operations; it ensures