Fix run deletion silently bypassing the active-lock check (#1445)

[mmido6039]

Fixes #1445

Problem

Deleting a run while it is actively being stored into (RunLock present)
was not actually being rejected. Reported by @bruntib:

1. Start storing a run.
2. While RunLock is active, remove the run via the CLI.
3. Storage finishes, but the run gets deleted anyway - the deletion
   should have been rejected.

Root cause

removeRun(run_id, run_filter) called
check_remove_runs_lock(session, [run_id]). The CLI's CodeChecker cmd del command always calls this with run_id=None, selecting runs to
delete via run_filter (e.g. by name) instead. This meant the lock
check ran as check_remove_runs_lock(session, [None]).

Since Run.id is never NULL, filtering Run.id.in_([None]) matches
zero rows unconditionally - the lock check silently passed regardless
of whether the targeted run was actually locked. I confirmed this with
an isolated reproduction of the exact query before making any changes.

Fix

Added get_run_ids_for_filter(), which resolves run_filter to the
concrete list of run ids it currently matches (reusing the existing
process_run_filter() helper). removeRun() now resolves the real
target run ids first, and only then checks those ids against active
locks - so it works correctly whether the caller identifies the run(s)
by id or by filter.

Testing

Added web/server/tests/unit/test_run_removal_lock.py with 4 tests
against an in-memory SQLite DB using the real ORM models:

• The exact bug scenario: resolving via a name-based RunFilter now
  correctly detects the active lock and raises.
• An unlocked run is not blocked.
• The old buggy call pattern (check_remove_runs_lock(session, [None])) is preserved as an explicit regression test documenting
  the root cause - it does not raise, showing why the bug occurred.
• An expired/stale lock does not block removal.

All new tests pass; pycodestyle clean; no changes to existing
behavior for callers that already pass a valid run_id.