Feature request: support fiber re-identity/rename across logical task reuse

Summary

We are integrating Tracy in HPX (https://github.com/TheHPXProject/hpx), a C++ runtime with a thread pool that recycles task objects (thread_data).

For fibers, Tracy identity is keyed by the const char* passed to TracyFiberEnter(...). In our scheduler, one recycled pool slot may execute many sequential logical tasks over time.

This means multiple logical tasks are attributed to the same Tracy fiber identity if they reuse the same pointer identity (per-slot behavior), which reduces per-task visibility.

Current behavior

• Fiber identity is tied to the pointer value passed to TracyFiberEnter.
• Reusing the same stable pointer across time reuses the same fiber track/identity.
• For runtimes with object recycling, this collapses multiple logical tasks into one fiber lane.

Why this is a problem

For M:N runtimes with short-lived tasks:

• Per-task visibility is lost (sequential tasks appear as one ongoing fiber identity).
• Generating a unique stable const char* per task is possible but problematic:
  • can cause unbounded memory/lifetime pressure,
  • may explode number of fiber tracks/events for short tasks.

Requested capability

A way to explicitly mark that the logical identity behind a fiber key changed at time t, without requiring a brand-new permanently stable const char* allocation per task.

Possible API directions (examples):

1. Explicit re-identity / rename event

   • TracyFiberReidentify(const char* fiberKey, const char* newName);
   • semantics: same execution context, but start a new logical fiber segment/track identity from this point.

2. Identity generation marker

   • TracyFiberGeneration(const char* fiberKey, uint64_t generation, const char* optionalName);
   • profiler keys fiber as (fiberKey, generation).

3. Close/open identity on same key

   • an explicit “end logical identity” marker and “begin new identity” marker for the same key.

Backward compatibility

No behavior change for existing users if API is unused. This would be an additive feature for runtimes that recycle task/fiber objects.

Additional context

We currently accept per-pool-slot tracks as a workaround. Disabling object recycling is not ideal (allocator reuse can still repeat addresses, and track count/UI overhead can become very high for short-lived workloads).