[cristianchiriac]

What this changes

search_filings(..., forms=[...]) no longer loses every original filing when the list contains an amendment code. EFTS returns amendments only as soon as forms holds a code like S-1/A, for every form in the list, while a root code (S-1) already matches its amendments. The issue measured ["F-1"] → 1 filing and ["F-1", "F-1/A"] → 0 for "YHTE".

_efts_forms() now builds the list sent to EFTS:

• X/A is dropped when X is also listed, so ["F-1", "F-1/A"] sends F-1 and ["S-1", "S-1/A", "F-1", "F-1/A", "424B4"] sends S-1,F-1,424B4.
• Amendment-only lists (["S-1/A"], ["S-1/A", "F-1/A"]) and lists without amendments are sent unchanged.
• An amendment code without its root mixed with other forms (["S-1/A", "F-1"]) is still sent as given, but raises a UserWarning that names the root form to use, because EFTS would leave out the other forms' originals.

Fixes #1544

Verification

• Regression test for a bug is in tests/issues/regression/test_issue_1544_search_forms_amendments.py, and its docstring links the issue. It stubs get_with_retry (as test_issue_1497.py does) and checks the forms parameter sent to EFTS for each case above, plus the warning. 4 of the 8 cases fail on main.
• Changelog: changelog.d/1544.fixed.md; assemble_changelog.py --check accepts it.
• tests/search and test_issue_1497.py (fast): 149 passed.
• I didn't record a live EFTS cassette. The EFTS behaviour itself is the one measured in the issue.

[arhancanli]

I checked the EFTS behaviour this PR relies on against a second form type, using the live endpoint on 2026-10-14 with q="Ford Motor", 2026-01-01 to 2026-10-14:

• forms=10-K → 194 hits
• forms=10-K/A → 5 hits, all 10-K/A
• forms=10-K,10-K/A → 5 hits, all 10-K/A (the 189 originals are gone, same as the F-1 case in search_filings(forms=[..., "S-1/A"]) silently drops every original filing #1544)
• forms=10-K restricted to 2026-04-29 (the filing date of one of those amendments, 0001628280-26-028367) → 1 hit, and its form is 10-K/A

So the root code does match its amendments for 10-K too, and dropping X/A when X is listed loses nothing there. The fix isn't specific to registration statements.

Review points on the diff, from reading it (I did not run the suite):

1. _efts_forms only matches a plain form[:-2] in listed. A case-variant like ["10-k", "10-K/A"] keeps the amendment and the user gets the amendments-only result again, silently, since the warning only fires when other non-amendment forms are present too. If search_filings doesn't normalise case upstream, a test for that input would show it.
2. The new tests cover the "mixed list" warning, but I don't see one for the all-amendments list with a root also present in a different position, e.g. ["S-1/A", "F-1/A", "S-1"] → expected F-1/A,S-1, which also triggers the warning because F-1/A has no root. That is the right behaviour but it's the one combination where the dropped and kept codes interact, so it is worth pinning.