Thanks to @achilleas-k pointing out a weird behavior when package dependencies are being pulled in from repositories with IDs not listed in the transaction `repo-ids`, I investigated the root cause.

The `repo_ids` field on depsolve transactions was supposed to restrict which repositories are used. DNF4's implementation used the `reponame` parameter of `install_specs()`, but that only filtered the explicitly requested packages — dependencies could still come from any enabled repository. DNF5 didn't implement `repo_ids` filtering at all. This PR fixes DNF4 and adds the missing implementation for DNF5, both using sack excludes to filter out packages from non-allowed repos before resolving.

1. 1. Key Changes

Instead of relying on DNF4's `reponame` parameter (which only filters top-level package selection), both solvers now use sack-level excludes to remove all packages from repos not in `repo_ids`. This is a more comprehensive approach that affects the entire dependency resolution, not just marking. Excludes are cleared and reapplied per transaction, so transactions with different `repo_ids` work correctly.

For DNF5, `GoalProblem_EXCLUDED` is now treated as a `MarkingError` (like `GoalProblem_NOT_FOUND`) via a bitmask check, making error reporting consistent with DNF4 when a package is only available in a filtered-out repo.

1. 1. Testing

Added a unit test that requests a package (`vim`) from `appstream` with only `appstream` in `repo_ids`. Since `vim` depends on packages in `baseos`, the depsolve correctly fails when `baseos` is excluded. The test also verifies that enabling both repos makes the depsolve succeed. Both DNF4 and DNF5 variants pass, along with the previously-skipped `error_pkg_not_in_enabled_repos` integration test for DNF5.

/jira-epic HMS-10032