Surface custom FTM, fact tags (_MILT, _PHOTO, etc.……) in get_events

[dmarshall-rgb]

GEDCOM allows vendor-specific extension tags (prefixed with an underscore) for facts an application supports beyond the standard tag set. Family Tree Maker uses many of these for custom facts like Military Service (_MILT), Primary Photo (_PHOTO), Employment (_EMPLOY), and others.

_get_events_internal's dispatch loop only recognized tags present in EVENT_TYPES or ATTRIBUTE_TYPES, so any underscore-prefixed custom tag was silently skipped entirely -- not mislabeled, but completely absent from the returned event list, with no indication anything was missing.

Fix: added a CUSTOM_TAG_TYPES lookup mapping known custom tags to friendly names/descriptions, and a catch-all branch (tag.startswith('_')) in both the direct-INDI and FAMS-driven family event loops. Known tags get their documented friendly name; any unrecognized underscore-prefixed tag still gets surfaced using the raw tag as its name, with a logged warning, rather than silently dropped -- so a newer FTM version introducing tags not yet in this list remains visible rather than regressing into the same silent-drop bug.

Also added INDI_ONLY_CUSTOM_TAGS, a set of tags documented as valid only under INDI records. If one of these unexpectedly appears under a FAM record, a placement_warning is attached directly to that event's returned data (in addition to a logged warning), since a warning would otherwise be invisible during normal MCP tool use -- surfacing it in the response itself makes it visible to whoever is actually using the tool.

CUSTOM_TAG_TYPES is compiled from third-party reverse-engineering, since Ancestry/Software MacKiev has never published an official FTM-to-GEDCOM tag specification. Sources: John Cardinal's GedSite/Gedcom Publisher FTM mapping pages (gedsite.com/en/familytreemaker.htm, gedcompublisher.com/en/familytreemaker.htm); Keith Rasmussen's 'Family Tree Software Alternatives' series on genealogytools.com (Part 1: How to Scrub Your Data; FTM-to-GEDCOM crosswalk spreadsheet); and Legacy Family Tree's cross-program custom-tag glossary (used for general context only, not FTM-specific). Coverage reflects roughly the FTM 2014-2019/MacKiev 2014.1-3.1 era; newer FTM builds could introduce tags not yet listed here, which is precisely why unrecognized tags are still surfaced generically rather than dropped.

Verified against Richard Wells III (@I2048@, real FTM export), whose _MILT fact was completely absent from get_events before this fix and now correctly surfaces as 'Military Service' with full date/place/source detail. A full-file scan found 43 real custom-tag facts across the tree (19 _MILT, 18 _PHOTO, 5 _EMPLOY, 1 _DEST), all now correctly surfaced with zero false placement warnings.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[dmarshall-rgb]

One thing worth flagging for merge sequencing: this PR was built independently from #7 (Fix get_sources and get_events missing event-level source citations), which adds a gedcom_ctx parameter to decode_event_details. This PR's two new call sites (the custom-tag handling in both the direct-INDI and FAMS-driven family loops) currently call decode_event_details(child_elem, tag) / decode_event_details(family_child, family_tag) with the current two-argument signature, since that's what's on main today.

If #7 merges first, decode_event_details's signature will require a third gedcom_ctx argument, and these two new call sites in this PR would need updating to match (a small change — just adding gedcom_ctx to both calls) or they'll raise a TypeError at runtime for any custom-tag event.

Happy to rebase this PR and update those two call sites once #7 merges, whichever is easier on your end — just wanted to flag the dependency now rather than have it surface as a confusing runtime error later.