JS reload (dev) with filters installed: network and breadcrumb events are lost, and on Android log lines are recorded unfiltered #135

Found while documenting the 7.x beta (docs PR bugsee/docs#110). Checked against the source on main at 7.0.0-beta3; file:line references are to the SDK repo unless a repo is named. Not reproduced on a device unless a line says so.

After a JavaScript reload the native filter bridges outlive the old runtime while the new runtime has not subscribed:

• Network and breadcrumb filters: the native filter stays installed (static flags: NetworkFilterBridge.java:171-181, BugseeModule.mm:457,1606-1616; BugseeModule.mm:627-632); the new module attaches as the sink (BugseeModule.java:146, BugseeModule.mm:1026), but the new runtime's JS has subscribed=false (src/network/filter.ts:74-77, src/breadcrumbs/filter.ts:75-78). Every event is offered to nobody until the app calls setNetworkFilter / setBreadcrumbFilter again. Android forgets each network event after 9 s and the SDK drops it at 10 s; iOS has no deadline, so each stays pending forever and is never recorded; breadcrumbs have no deadline on either platform.
• Log filter, Android: the new module calls LogFilterBridge.shared().setEnabled(false) (BugseeModule.java:150), so log lines are recorded unfiltered until the new runtime calls setLogFilter. This is a privacy gap (a redaction the app relied on silently stops applying). iOS keeps BGSRNLogFilterUserEnabled set and drops the lines instead.

Mostly a development-time scenario (Fast Refresh / reload), but a release app can also tear down and recreate the bridge.

Suggested direction

• On module creation, re-subscribe or reset the bridges consistently: either drop back to a fail-closed state (hold or drop, never record unfiltered) until JS answers, or replay the "filter is set" state from the new runtime.
• Make the Android log bridge fail closed on reload, like iOS, until a filter is set or explicitly cleared.