fix: follow-up enhancements for AlmaLinux available_fix

[VanitasCodes]

Fixes #5597

This PR addresses the follow-up items identified after merging the AlmaLinux available_fix feature.

The main change is deduplicating packages across architectures in the errata processing. Previously, when AlmaLinux published fixes for multiple architectures (x86_64, aarch64, s390x, etc.), each architecture variant appeared as a separate line in the output. Now packages differing only by architecture are collapsed into a single entry, making the output cleaner and easier to read.

An online integration test has been added to verify the AlmaLinux errata API integration works correctly. The test uses a known CVE (CVE-2022-1271 in xz) that has been fixed in AlmaLinux 9, ensuring the logic doesn't get out of sync with the actual data provided by the server over time.

Two minor fixes are also included: adding the missing newline at the end of spelling/expect.txt to resolve the spelling check warning, and converting a legacy %s string format to an f-string for consistency with the rest of the codebase.

All unit tests pass, and manual end-to-end testing with curl-7.76.1-29.el9_4.1.x86_64.rpm confirms the deduplication works as expected.

[Copilot]

Pull request overview

This PR improves the AlmaLinux available_fix reporting by collapsing duplicate fixed-package entries that differ only by architecture, and adds an online integration test to validate the AlmaLinux errata API integration over time.

Changes:

• Deduplicate AlmaLinux advisory packages by (name, version, release) during errata processing to avoid repeated output lines per architecture.
• Add an external (online) AlmaLinux available-fix integration test using a known CVE.
• Fix minor repo hygiene items (newline at EOF for spelling expectations; replace legacy logger formatting).

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 2 comments.

File	Description
test/test_available_fix.py	Adds a long/online AlmaLinux integration test and corresponding mock CVE input data.
cve_bin_tool/available_fix/alma_cve_tracker.py	Deduplicates fixed package entries across architectures and modernizes a warning log format.
.github/actions/spelling/expect.txt	Ensures the file ends with a newline (spelling action expectation file).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This online integration test asserts an exact fixed package version/release/advisory string. Since AlmaLinux errata can be updated over time (e.g., a newer advisory or release for the same CVE), the logic could remain correct but this test would fail. Consider asserting more stable invariants instead (e.g., that at least one log line reports Status: Fixed for CVE-2022-1271 on AlmaLinux 9, and optionally that the advisory prefix matches ALSA-2022:4940), rather than pinning the full package NEVRA fragment.

Suggested change

	expected_output = [
	"xz: CVE-2022-1271 - Status: Fixed - Fixed package: xz v5.2.5-8.el9_0 (Advisory: ALSA-2022:4940; AlmaLinux 9)",
	]
	assert expected_output == [rec.message for rec in caplog.records]
	messages = [rec.message for rec in caplog.records]
	# Assert that at least one log line reports this CVE as fixed on AlmaLinux 9
	assert any(
	("xz:" in msg)
	and ("CVE-2022-1271" in msg)
	and ("Status: Fixed" in msg)
	and ("AlmaLinux 9" in msg)
	for msg in messages
	)
	# Optionally, assert that the advisory identifier has the expected prefix,
	# without pinning the entire NEVRA or full advisory string.
	alma_msgs = [msg for msg in messages if "CVE-2022-1271" in msg]
	assert alma_msgs
	for msg in alma_msgs:
	if "Advisory:" in msg:
	advisory_part = msg.split("Advisory:", 1)[1].split(";", 1)[0].strip()
	assert advisory_part.startswith("ALSA-2022:4940")
	break
	else:
	pytest.fail("No advisory information found for CVE-2022-1271 in AlmaLinux output")

[VanitasCodes]

Following the established pattern used by test_long_redhat_available_fix_output and test_long_debian_available_fix_output which also use exact string matching.

[Copilot]

The new deduplication logic in Alma errata processing (collapsing identical name/version/release across architectures) isn't exercised by the mocked AlmaLinux unit test data (MOCK_ALMA_API only has a single package entry). To prevent regressions, add/adjust an offline test case where the mocked advisory contains duplicate package entries (as would happen with multiple architectures) and assert that only one line is emitted.

[VanitasCodes]

Right, the current mock data doesn't exercise the deduplication logic. @alex-ter, would you like me to update MOCK_ALMA_API to include multiple architecture entries so the offline test covers deduplication?

[VanitasCodes]

@alex-ter @ffontaine The online test is failing in CI due to errata.almalinux.org being unreachable from the GitHub Actions runner (connection refused). The test passes locally. Is AlmaLinux's domain blocked in CI, or should I add retry/skip logic for network failures?

[alex-ter]

@alex-ter @ffontaine The online test is failing in CI due to errata.almalinux.org being unreachable from the GitHub Actions runner (connection refused). The test passes locally. Is AlmaLinux's domain blocked in CI, or should I add retry/skip logic for network failures?

You'll need to update the respective allowed-endpoints list(s) in .github/workflows/testing.yml.

[VanitasCodes]

@alex-ter Ready for review.