Performance spans: setName() sets the operation, finish() with no argument overwrites a set status, thread differences, dev reload leaves transactions open, sampled is a snapshot #146

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.

• span.setName() sets the operation, not the transaction name, on both SDKs (src/apm/span.ts).
• finish() with no argument ends the span as OK and overwrites an earlier setStatus (Android SpanImpl.finish() -> finishByInstrumentation(OK); iOS BGSSpanImpl -finish -> finishWithStatus:OK); open children are ended with Cancelled. The JS status property is not updated by finish.
• Span calls run on different threads: iOS hops to the main thread synchronously, Android stays on the calling thread.
• A dev reload releases span handles without finishing them, so open transactions stay open in the SDK.
• sampled is read once when the transaction starts (BugseeModule.java:1740, BugseeModule.mm:911) and never updated: a transaction promoted by adaptive sampling when it finishes still reads false. The standalone APM upload is not wired in either SDK (Android: commented out in BugseePerformanceCoordinator.java:220-231 at 7.4.2; iOS: "not currently wired"), so sampling and upload-mode options have no effect in this beta.

Suggested direction

Fix setName, keep status in sync after finish, and finish or cancel open spans when the runtime goes away.