dillon1000/react

[DevTools] Fix printOperationsArray decode of applied activity slice change (#36935)

`printOperationsArray` in `react-devtools-shared` walks an operations
array under
the invariant that each `switch` case leaves `i` pointing at the next
opcode (loop
header at `packages/react-devtools-shared/src/utils.js`).

The `TREE_OPERATION_APPLIED_ACTIVITY_SLICE_CHANGE` case broke that
invariant:

```js
case TREE_OPERATION_APPLIED_ACTIVITY_SLICE_CHANGE: {
  i++;                                        // skip opcode -> i now at the value slot
  const activitySliceIDChange = operations[i + 1]; // reads the slot AFTER the value; i not advanced
  ...
}
```

The operation is exactly two slots, `[opcode, activitySliceID]` (see the
writer in
`packages/react-devtools-shared/src/backend/fiber/renderer.js`, which
pushes the
opcode then the id). So the case did two things wrong:

1. It logged the wrong number: `operations[i + 1]` reads the slot
*after* the
value (the next operation's opcode, or `undefined` at the end of the
array).
2. It left `i` pointing at the value slot, so the outer `while (i <
operations.length)` loop re-read the activity-slice id as an opcode. For
any
non-zero slice id that falls through to `default: throw
Error("Unsupported
   Bridge operation ...")`, aborting the whole dump.

The two canonical decoders of this same operation both use the correct
pattern
(skip the opcode, then read *and* advance past the value):

- `devtools/store.js`: `i++; nextActivitySliceID = operations[i++];`
- `devtools/views/Profiler/CommitTreeBuilder.js`: `i++; const
activitySliceIDChange = operations[i++];`

This change makes `printOperationsArray` match them by reading
`operations[i++]`.

This is a debug-only diagnostic path: the only caller is the
`__DEBUG__`-guarded
dump in `backend/legacy/renderer.js`, so it is not a production crash.
The bug was
introduced in #34908.

## How did you test this change?

Added a regression test for `printOperationsArray` in
`packages/react-devtools-shared/src/__tests__/utils-test.js`. The
fixture chains
two activity-slice operations, `[rendererID, rootID, stringTableSize=0,
opcode, 42,
opcode, 0]`; the trailing operation is what forces the reader to advance
past the
first value slot rather than re-read it. It asserts the call does not
throw, logs
once, and that the message contains both `Applied activity slice change
to 42` and
`Reset applied activity slice`.

Ran the DevTools Jest project (built first, as that project requires a
build):

- With the fix: 51/51 pass, including the new test.
- Reverting only the one-line fix back to `operations[i + 1]` and
rebuilding: the
new test fails with `Unsupported Bridge operation "42"` (exactly the
predicted
  failure), 50 pass / 1 fail. Restored the fix and it is green again.

`yarn prettier-check` and `yarn linc` are clean on the changed files.