Fix the quarantine step in a failing ETL job

An ETL job (it extracts, transforms and loads data) keeps crashing on rows it cannot parse, and the on-call AI proposed wrapping the parse in try/except: pass. That stops the pages by dropping bad rows without a trace. Your team's mitigation instead quarantines each bad row by id, counts it, and raises an alert when too many rows go bad.

An assistant wrote apply_etl_mitigation(row_lines, alert_threshold_percent). It is in the editor. It has a bug. Find it and fix it.

Input and output:

• row_lines: the batch, one string per row, written id|value.
• alert_threshold_percent: the share of bad rows, as a whole percent, that the batch may reach without an alert.
• Return a list of strings: "accepted=<A>", "quarantined=<Q>", "bad_pct=<P>", "alert=yes" or "alert=no", then one "quarantined_id=<id>" per bad row in input order.

Rules the tests check:

• Every entry in row_lines is a row, including an empty or blank one.
• Split a row on |. The id is the first part with whitespace trimmed from both ends, or unknown if that is empty. The value is the second part, trimmed, or empty if there is no second part. Further parts are ignored.
• A row is good when its value is an optional - followed by one or more digits 0 to 9, and nothing else. Every other row is bad and is quarantined.
• P is the number of bad rows times 100, divided by the number of rows and rounded down. It is 0 when there are no rows.
• A threshold below 0 counts as 0. The alert is yes when there is at least one row and bad rows times 100 is greater than the threshold times the number of rows. Otherwise it is no.