fix: isolate inherited hubs under hub_isolation_level = :fiber

[SeanLF]

Fixes the :fiber isolation level, which did not isolate anything. Reported by @trevorturk in #3018.

The bug

Fiber storage is inherited by child fibers and by threads started from a fiber, and the inherited value is the same object. Once anything seeds a hub in an ancestor fiber, every sibling request fiber and every worker thread shares one Hub, along with its unsynchronized @stack.

Reproduced on master (Ruby 4.0):

• 4 threads spawned after the seed: 1 hub instead of 4
• 4 concurrent jobs in with_scope: every one read another job's tags
• 3 sibling request fibers: 1 hub instead of 3

The || clone fallback in get_current_hub never fires in those contexts, because the inherited value is not nil.

The fix

Tag each stored entry with its owning fiber. A context that reads an entry it did not store gets its own copy instead of sharing.

The copy is a fork, not Hub#clone: private scope stack, but the live span. Without that, Scope#dup deep-dups the span, Transaction#deep_dup builds a fresh SpanRecorder, and every child-fiber span lands on a detached transaction copy that is never sent. Async fan-out inside a request is the workload this mode exists for.

Fiber contexts now behave like thread contexts (own hub, own scope stack) and stay on the same trace.

Behaviour change

The spec asserting a child fiber gets the same hub object is inverted: it now asserts the child gets the parent's context in its own hub. Sharing the object is what caused the leak.

Sentry.last_event_id and the per-hub profiler registry do not cross the boundary, matching existing :thread behaviour.

Testing

• 1416 examples, 0 failures on Ruby 3.2 (Docker), 3.4 and 4.0
• The four isolation specs fail without the change. The span spec passes before it (sharing a hub did record the spans) and fails if the fork is replaced with a plain Hub#clone, so it guards the fix rather than the original bug
• Fiber semantics verified identical on 3.2 / 3.3 / 3.4 / 4.0. On Ruby < 3.2 and JRuby the fiber-storage gem polyfills Fiber[], so :fiber is active there too; the polyfill inherits into child fibers (same bug, same fix) but not into Thread.new, so a thread there already starts from the main hub
• Hot path costs about 26ns more per get_current_hub (50ns to 77ns), no extra allocations. The fork runs once per new context and is O(spans)