FPL parsers: only look for field 13 at index 3 or 4 (Swift + Python) #31

Problem

Both FPL parsers find field 13 by its shape (^[A-Z]{4}HHMM$ with a valid time) and take the first match from field 9 onward. If field 13 itself is malformed (e.g. -EGLL99, bad time), the scan keeps going and a field 16 with no alternate (-EGSS0025) has exactly that shape, so it is taken as field 13: departure becomes the destination airport, and field 15 is read from the wrong slot (no route).

Field 13 can only sit at index 3 (fields 9/10 joined) or 4 (fields 9/10 split), so scanning past index 4 adds no valid case and creates this one.

Raised in the Owner's brief of #29 ("Follow-ups noticed"); documented today as a gotcha in designs/briefing_models.md ("Locating Field 13") and designs/swift_briefing.md (Gotchas).

Call sites (both must change together, for parity)

• Swift: Sources/RZFlight/Briefing/ICAOFlightPlanParser.swift:178
fields.indices.dropFirst(2).first { isField13(fields[$0]) } ?? 3
• Python: euro_aip/euro_aip/briefing/models/icao_fpl.py:219
next((i for i in range(2, len(fields)) if _is_field13(fields[i])), 3)

Proposed change

Restrict the scan to indices 3 and 4 (keep the fallback to 3). Keep the split-9/10 rule (field13_idx > 3 → slot 3 is field 10).

Acceptance criteria

• Both parsers scan only indices 3..4; fallback to 3 unchanged.
• New test on both sides: malformed field 13 + field 16 with no alternate → departure is not the field-16 airport (departure None/raw per the existing malformed handling), destination still parsed from field 16.
• All existing FPL tests still pass on both sides (euro_aip/tests/briefing/test_icao_fpl.py, Tests/RZFlightTests/RZFlightFPLTests.swift), including the split 9/10 + no 18/19 case from Python FPL parser: find field 13 by shape, as Swift does (split 9/10 with no 18/19 misparses) #26.
• Remove the gotcha from both design docs.
• Swift change ships on merge (Swift consumers track main); Python with the next euro_aip release (patch).