Other pattern: the XLSForm companion question stays in the LimeSurvey TSV with a relevance that never holds

[jstet]

When convertOtherPattern collapses the XLSForm "other" pattern (a choice other plus a <question>_other text row) into LimeSurvey's native other=Y, the converter still emits the companion text question. Its relevance can never be true:

Entity	Companion relevance in the TSV	Why it never holds
select_one_other	aufmerksam == 'other'	LimeSurvey stores -oth- for the native "other" of a list
select_multiple_other	(geraetebesitz_other.NAOK == 'Y') (was geraetebesitz == 'other' before the fixture used selected())	geraetebesitz_other holds the typed text, not Y; a multiple choice has no single value

So the companion is always hidden. LimeSurvey's native "other" text box collects the text, and the live response round-trip confirms it (geraetebesitz[other]). The companion is dead weight: an extra always-hidden question in the imported survey, and an extra empty column in the response export.

To decide:

• Drop the companion question when the pattern is collapsed into other=Y. The reverse (lstsv2xlsform) and lstsv2ddi already rebuild <question>_other from other=Y, so no information is lost.
• Or keep it and give it a relevance that actually holds, e.g. !is_empty(geraetebesitz_other). That duplicates the native box.

Found while fixing the skill's or_other guidance (the select_multiple_other example used = instead of selected()).

[jstet]

The companion is emitted under its sanitized name, <question>other without the underscore (e.g. geraetebesitzother, aufmerksamother), not <question>_other. So a consumer check for a Q row named <question>_other passes although the companion is there. formulaid's e2e suite noticed this. After the fix, assert that no Q row with the companion's sanitized name exists.