Unchecked file-declared counts overflow fixed-size buffers in five PDB driver readers

`db_pdb_GetMaterial` reads the stored `dims` component straight onto a fixed member of a stack struct, with nothing carrying the destination size.

`tmpmm` is a `DBmaterial` (silo_pdb.c:3297, 144 bytes here) and `dims` is `int dims[3]`. `DEFINE_OBJ` registers the bare address with the "already allocated" flag (silo_pdb_private.h:330-337), so `PJ_ReadVariable` ends up doing a plain `PJ_read` at silo_pdb.c:1140, and the length of that read is whatever element count the file declares. `ndims` is never compared against 3.

No hex editing needed, because `DBPutMaterial` only rejects a negative `ndims` (silo.c:9535) and will write the file for you:

```c
int dims[1000]; for (int i=0;i<1000;i++) dims[i]=1;
DBPutMaterial(f,"mat","mesh",1,matnos,matlist,dims,1000,
NULL,NULL,NULL,NULL,0,DB_FLOAT,NULL); /* returns 0 */
```

Reading that file back, ASan reports a stack-buffer-overflow WRITE of size 4000 into a 144-byte frame object, from `fread` in `_PD_rd_leaf_members` up through `db_pdb_GetMaterial` silo_pdb.c:3332. A plain release build exits 139, stopping in `__stack_chk_fail`.

Four more of the same shape, briefly:

- `db_pdb_GetQuadmesh` fills `base_index[3]` in a loop bounded by the file's `ndims` (silo_pdb.c:5132). At `ndims` 13 it stays inside the allocation, so nothing warns, but `mrgtree_name` comes back as `0x4141414141414141` from the file's `origin` and `DBFreeQuadmesh` then aborts.
- `db_pdb_GetUcdvar` indexes the ten-element `_valstr` table with the file's `nvals` (silo_pdb.c:5775). `DBPutUcdvar` accepts 200. Same pattern at :4973, :5290, :5986, :7544.
- `db_pdb_GetGroupelmap` walks `segment_data` bounded only by the file's `segment_lengths` (silo_pdb.c:7420-7428).
- `db_StringListToStringArrayMBOpt` sizes `strArray` from `nblocks` but writes one entry per token found (silo.c:13825-13840); the `n != nblocks` check at :13887 runs after the loop.

I built main at ac496f8 and ran all five. Happy to send the reproducers, or open a PR if that is more useful.

Filing in the open since there is no SECURITY.md and private reporting is off, and #246 was handled this way. #540 touched these files but its hunks are elsewhere.

I used an AI assistant while tracing the call paths; the builds and runs are mine.