Mark issues in FixupBase abstract

[agners]

Proposed change

Since #5024 all fixups have an associated issue. Generally, it is generally better to have an issue for every fixup so that things can be mapped to repairs in Core easily. Let's mark the issues property as abstract to indicate subclasses are required to implement it.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (which adds functionality to the supervisor)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:
• Link to cli pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Ruff (ruff format supervisor tests)
• Tests have been added to verify that the new code works.

If API endpoints of add-on configuration are added/changed:

• Documentation added/updated for developers.home-assistant.io