satTle2elem: type 4 sets run as SGP4, and three ways one set fails the whole file #1676

Describe the bug
hey, following up on #1673: running the TLE reader through gpconf turned up four things in tleHandling.py:

• a blank international designator (line 1, columns 10-17) raises invalid literal for int() with base 10: ' ' for the whole file. CelesTrak leaves it blank for analyst objects, so their analyst TLE file (219 sets) loads none
• ephemeris type 4 (SGP4-XP) sets get run through plain SGP4 and labelled SDP8, while satOmm2elem already refuses the same set
• a 3LE name starting with 1 or 2 (like 1KUNS-PF or 2026-195B) gets counted as an element line, so the file is refused
• one bad set (wrong checksum, a typo in a number) raises and every other set in the file is lost, where satOmm2elem skips the bad record and keeps going

To reproduce
Each one with Basilisk's own examples/MultiSatBskSim/tleData/hypso1.tle:

1. blank columns 10-17 of line 1 (and fix the checksum): satTle2elem raises
2. set line 1 column 63 to 4 (and fix the checksum): it loads with no warning
3. change the name line to 1KUNS-PF: satTle2elem raises
4. three sets with one checksum digit changed in the middle one: it raises and returns none

Expected behavior
1 loads, 2 is refused like the OMM reader does, 3 loads, 4 skips the bad set with a warning and returns the other two.

Desktop

• OS: macOS 27.2.1
• Version: develop 016955f
• Python version: 3.14.6

Additional context
I have a fix with tests for each, one commit apiece, and it doesn't touch your #1675 changes. Opening a PR for it.