Add test for ReviewerControlPreference.getPreferenceAssignedTo (#13283)

[GuTS805]

Covers side-specific binding lookup: a binding on QUESTION/ANSWER only matches a preference on
the same side, while a binding on BOTH conflicts with any single-side binding. Verified via
mutation testing that re-introducing the bug (ignoring the card side) breaks the test.

Fixes part of #13283

Purpose / Description

ReviewerControlPreference.getPreferenceAssignedTo had no test coverage (@NeedsTest("Ensure correct preference is returned for side-specific binding")). This is one of many @NeedsTest
items tracked in #13283 — only this single method is covered here, per the maintainer's stated
preference elsewhere in that thread to keep PRs to one test at a time.

Approach

Added ReviewerControlPreferenceTest covering three cases: a binding on the same side is found,
a binding on a different side is not found, and a binding on CardSide.BOTH conflicts with a
single-side binding. Since getRelatedPreferences() matches preferences by exact class
(it::class == ReviewerControlPreference::class), the test uses real ReviewerControlPreference
instances (not a subclass) and accesses the protected side field and getPreferenceAssignedTo
method via reflection, following the existing pattern in NumberRangePreferenceCompatTest.

How Has This Been Tested?

Ran the new test in isolation and confirmed it fails when the side-overlap logic is broken
(temporarily changed ReviewerBinding(binding, cardSide) to always use CardSide.BOTH, confirmed
the "different side is not found" test failed, then reverted). Also ran the full
com.ichi2.preferences.* test package with no regressions.

Learning (optional, can help others)

ReviewerBinding.equals() treats CardSide.BOTH as conflicting with any other side, and two
same-typed sides as conflicting with each other — that's the "side overlap" logic this method
relies on via getPreferencesAssignedTo.

Checklist

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[welcome]

First PR! 🚀 We sincerely appreciate that you have taken the time to propose a change to AnkiDroid! Please have patience with us as we are all volunteers - we will get to this as soon as possible.

[david-allison]

This doesn't look self-reviewed: we've moved to SPDX copyright headers, and if you wish to add your name/email, it should be yours, not mine :D

• #20954 for SPDX

[david-allison]

LGTM! One nitpick to be sure we're testing the behaviour we depend on

[david-allison]

LGTM!

[GuTS805]

Thanks for the review.