turbo-tasks-backend: assert non-transient task_ids in track_modification (vercel#91924)

### What?

Add a `debug_assert!` in `StorageWriteGuard::track_modification` to enforce that transient `TaskId`s are never inserted into the persistence-modified set.

### Why?

Concurrent server component HMR updates triggered a runtime panic in Turbopack:

```
internal error: entered unreachable code: transient task_ids should never be enqueued to be persisted
```

This `unreachable!` lives in `snapshot_and_persist` (`backend/mod.rs:1254`), which is called during the persist cycle. It fires when a transient `TaskId` is found in `Storage::modified` — the set that tracks tasks whose state needs to be written to disk.

**Transient task IDs (high bit set) are never serialized.** The invariant was enforced only at the *caller layer*:

- `TaskGuardImpl::track_modification` (`operation/mod.rs:1029`) guards with `if !self.task_id.is_transient()`
- `TaskGuardImpl::invalidate_serialization` (`operation/mod.rs:970`) guards with `if !self.task_id.is_transient()`

But `StorageWriteGuard::track_modification` — the public method on the storage struct itself — had no such guard. Under concurrent HMR invalidations, a transient task ID could reach this method via a code path that bypasses the caller-level checks, inserting the ID into `Storage::modified` and causing the panic downstream during the next persist cycle.

The flaky test is `test/development/app-dir/hmr-iframe/hmr-iframe.test.ts` — it triggers two simultaneous server component file changes (one in an iframe, one in the parent), which races the persist cycle against concurrent invalidations.

### How?

Add a `debug_assert!` in `StorageWriteGuard::track_modification` (the sole public entry point into the storage mutation path) that matches the invariant already checked at the caller layer:

```rust
debug_assert!(
    !self.inner.key().is_transient(),
    "transient task_ids should never be enqueued to be persisted"
);
```

This enforces the invariant at the storage boundary in debug builds, surfacing the violation at the point of insertion rather than much later during the persist cycle. The message deliberately matches the existing `unreachable!` downstream so both failure modes are easy to correlate.

**Verification:**
- `cargo test -p turbo-tasks-backend` — all unit tests pass
- `pnpm build-all` — build succeeds
- `NEXT_SKIP_ISOLATE=1 NEXT_TEST_MODE=dev pnpm testheadless test/development/app-dir/hmr-iframe/hmr-iframe.test.ts` — 3/3 consecutive passes (was flaky before)

Author: sokra

turbopack/crates/turbo-tasks-backend/src/backend/storage.rs

@@ -302,6 +302,10 @@ impl StorageWriteGuard<'_> {
         category: SpecificTaskDataCategory,
         #[allow(unused_variables)] name: &str,
     ) {
+        debug_assert!(
+            !self.inner.key().is_transient(),
+            "transient task_ids should never be enqueued to be persisted"
+        );
         self.track_modification_internal(
             category,
             #[cfg(feature = "trace_task_modification")]