MeshFile element-code check is a tautology and does nothing

`mikecore/MeshFile.py` (around line 281, in `ReadMesh`) contains:

```python
# Element code must be 21 or 25 (21 for triangular meshes, 25 for mixed meshes)
if (elmtCode != 21) or (elmtCode != 25):
pass # TODO?? Do we care?
```

The condition is a tautology: no integer can be equal to both 21 and 25, so `!= 21 or != 25` is true for every possible value — including the two the comment says are valid. It needs `and`.

Today this is harmless, because the body is `pass`. The problem is the invitation: the `TODO` asks someone to decide what to do with an unexpected code, and anyone who fills the body in — with a `raise`, a warning, anything — makes it fire on *every* mesh, valid ones included.

The check is also redundant as written. A few lines further down, `ElementType` is derived per element from the number of corners actually parsed, so the header code is not what the reader relies on.

Two things to settle:

1. Remove the dead block so the trap is gone. (Doing this in a PR alongside this issue.)
2. Decide the policy: should an element code other than 21 or 25 raise, warn, or continue to be ignored? Right now `elmtCode` is read from the header and never used for anything.

Start in mikecore/MeshFile.py at ReadMesh around line 281, then follow how elmtCode and the later ElementType derivation are used. Confirm whether the header code has any required role, decide the behavior for codes other than 21 and 25, and ensure the dead tautological block is removed without changing valid mesh parsing.

Written by the indexing model from the issue text.