Fix trailing whitespace and a shadowed gettext _ in AssociationsTool

[eduralph]

Problem

Two pre-existing defects on maintenance/gramps60 that the addon CI pipeline (#820) surfaces the moment its lint gate runs:

1. Trailing whitespace on three tracked Python files (27 lines): ArchiveAssist/ArchiveAssist.py (22), FilterRules/matcheventfilterrole.py (4), FilterRules/matchparentoffilterfamily.py (1). The pipeline's trailing-whitespace check fails on them.

2. A real latent bug in AssociationsTool: _build_with_progress() uses for _ in range(batch_size), which makes _ a function-local throughout the method and shadows the module-level _ = _trans.gettext. On the error paths this raises UnboundLocalError (the _("Error initializing data: %s") handler, which references _ before the loop binds it) and TypeError (the in-loop _("Error processing person …") handler, which calls _ after the loop bound it to an int). ruff F82 flags it.

Fix

• Strip the trailing whitespace (whitespace-only; git diff -w is empty).
• Rename the unused loop counter to _batch_step so _ resolves to the gettext function everywhere in the method.

Four files, no pipeline/CI files. Splitting these out of #820 so that PR stays pipeline-only; #820's lint lane goes green once this merges and is merged back. Found while running #820's own gates against the tree during an adversarial review of that PR.

[romjeromealt]

A real latent bug in AssociationsTool: _build_with_progress() uses for _ in range(batch_size), which makes _ a function-local throughout the method and shadows the module-level _ = _trans.gettext. On the error paths this raises UnboundLocalError (the _("Error initializing data: %s") handler, which references _ before the loop binds it) and TypeError (the in-loop _("Error processing person …") handler, which calls _ after the loop bound it to an int). ruff F82 flags it.

My bad, I did not see it during review for #976
Also, testing was under gramps52. Also, as translation strings (related to _ variable) were loaded at first runtime (or addon load), such backend hidden method did not always raise an error? e.g., batch size < 50. Anyway, good catch. Thanks!

[romjeromealt]

There was a blind change (according to my working branch) on #967 (gramps52)
Also read that it seems to have a change on translation handling into gramps60 and +.

IA pointed out possible issues, but this one was not explicit (there was two locations...), despite matched.

Solution:

    Never use _ or LOG as variable names in loops or unpacking.
    Use explicit variable names (e.g., privacy, citation, note) if you must unpack tuples.
    Better yet: avoid unpacking entirely by using the public API (Fix 1).

Example of What to Avoid:

for ref in person.serialize()[-1]:
    _, _, _, two, value = ref  # ❌ Shadows gettext's _
    # or
    LOG, _, _, two, value = ref  # ❌ Shadows the LOG logger

#967 (comment)

[eduralph]

A real latent bug in AssociationsTool: _build_with_progress() uses for _ in range(batch_size), which makes _ a function-local throughout the method and shadows the module-level _ = _trans.gettext. On the error paths this raises UnboundLocalError (the _("Error initializing data: %s") handler, which references _ before the loop binds it) and TypeError (the in-loop _("Error processing person …") handler, which calls _ after the loop bound it to an int). ruff F82 flags it.

My bad, I did not see it during review for #976 Also, testing was under gramps52. Also, as translation strings (related to _ variable) were loaded at first runtime (or addon load), such backend hidden method did not always raise an error? e.g., batch size < 50. Anyway, good catch. Thanks!

No worries - it surfaced during my work on a CI for addons-source, so it's doing what it's supposed to. :-)