### Website or app

https://github.com/reactjs/reactjs.org/pull/4981

### Repro steps

1. Wrap something into `<Fragment key="stuff">`
2. It doesn't show up in DevTools

We filter out fragments because they tend to be useless. But this one is important! Keys are crucial and we should show anything with a key in the tree.

### How often does this bug happen?

Every time

### DevTools package (automated)

_No response_

### DevTools version (automated)

_No response_

### Error message (automated)

_No response_

### Error call stack (automated)

_No response_

### Error component stack (automated)

_No response_

### GitHub query string (automated)

_No response_
function getFiberIDUnsafe(fiber: Fiber): number | null {
    if (fiberToIDMap.has(fiber)) {
      return ((fiberToIDMap.get(fiber): any): number);
    } else {
      const {alternate} = fiber;
      if (alternate !== null && fiberToIDMap.has(alternate)) {
        return ((fiberToIDMap.get(alternate): any): number);
      }
    }
    return null;
  }
   Removes a Fiber (and its alternate) from the Maps used to track their id.
   This method should always be called when a Fiber is unmounting.
  function untrackFiberID(fiber: Fiber) {
    if (__DEBUG__) {
      debug('untrackFiberID()', fiber, fiber.return, 'schedule after delay');
    }
     Untrack Fibers after a slight delay in order to support a Fast Refresh edge case:
     1. Component type is updated and Fast Refresh schedules an update+remount.
     2. flushPendingErrorsAndWarningsAfterDelay() runs, sees the old Fiber is no longer mounted
        (it's been disconnected by Fast Refresh), and calls untrackFiberID() to clear it from the Map.
     3. React flushes pending passive effects before it runs the next render,
        which logs an error or warning, which causes a new ID to be generated for this Fiber.
     4. DevTools now tries to unmount the old Component with the new ID.
    
     The underlying problem here is the premature clearing of the Fiber ID,
     but DevTools has no way to detect that a given Fiber has been scheduled for Fast Refresh.
     (The "_debugNeedsRemount" flag won't necessarily be set.)
    
     The best we can do is to delay untracking by a small amount,