# DF-3514 — ng_ID_rehash/ng_name_rehash: entries not unlinked (non-INVARIANTS) + wrong destroy mask -> kernel panic

## What

`sys/netgraph7/netgraph/ng_base.c`:

* `ng_ID_rehash()` (lines 973-999): the migration loop unlinks nodes from
  the old ID-hash **only under `#ifdef INVARIANTS`** (lines 988-990). On
  production (non-INVARIANTS) kernels — and in any standalone KLD module
  build, which does not inherit the kernel's INVARIANTS flag — every node
  stays linked into the OLD table and is additionally inserted into the new
  one. `hashdestroy()` on the still-populated old table then panics
  ("hashdestroy: hash not empty"). Independently, line 996 passes the WRONG
  mask: `hashdestroy(ng_ID_hash, M_NETGRAPH_NODE, ng_name_hmask)` — the
  name-hash mask instead of `ng_ID_hmask`; if the name hash is smaller than
  the ID hash the walk under-runs, if larger it walks OOB past the old table.
* `ng_name_rehash()` (lines 941-967): same INVARIANTS-only `LIST_REMOVE`
  (lines 956-958); destroy mask is correct here but the un-migrated old
  table still triggers the same panic.

Double-insertion is also a list-corruption UAF: when such a node is later
freed via one list, the other list keeps a dangling pointer.

## Reachability

Rehash fires when `ng_nodes * 2 > ng_ID_hmask` (8 live/leaked nodes for the
initial 16-bucket table) at `ng_make_node_common()` (line 657-658), and when
named nodes cross the equivalent threshold in `ng_name_node()`. Node counts
inflate permanently via the reference leaks in DF-3513 (drained conq items
pin their `el_dest` node) and DF-3515 (callout items pin their node while
armed/stopped) — so routine bluetooth traffic or any repeated graph
build/teardown eventually crosses the threshold; the NEXT node creation
(its caller can be any subsystem creating a netgraph node, e.g. a socket)
panics the kernel.

## Reproduced

4 panics on the QEMU guest (3x via `ng_make_node_common` during
`ngc_attach`, 1x via `ng_name_node` after only the ID-rehash half was
fixed), all "hashdestroy: hash not empty". Traces in panic.txt.
Fix (unconditional LIST_REMOVE + correct mask, both functions) validated at
module level: after the fixed core module was loaded, 20 consecutive
DF-3513 PoC cycles (each previously sufficient to cross the threshold and
panic) completed with exit 0 and no panic.

## Reproduce (same harness as DF-3513)

build+load ng7 modules (unfixed), then repeatedly: `./poc_leak 500`
(each run pins nodes via the leaks). Panic occurs within ~3-8 runs.
With the fixed core module: 20/20 runs survive.