test: concurrent-invite race test is flaky on the sqlite-file backend (admission_conflict) #855

`modules/tenants/tests/test_owner_race.py::test_concurrent_invites_to_one_address_give_one[sqlite-file]` failed once in CI on PR #854, which does not touch tenants, and passed on re-run:

```
AssertionError: assert ['admission_c...nvited', 'ok'] == ['already_inv...nvited', 'ok']
```

Five concurrent invites to one address on a SQLite file DB: one loser came back with `admission_conflict` (`ERROR_ADMISSION_CONFLICT`, "someone else changed this organisation at the same moment") instead of `already_invited`. Both refuse the duplicate and only one invitation row exists, so the behaviour is safe; the test asserts the more specific code.

Options:

• accept either refusal code in the test for the SQLite backend (the admission conflict is a legitimate outcome under write contention), or
• have the invite path re-check for an existing pending invitation after an admission conflict and report `already_invited`.

CI run: https://github.com/antosubash/simple_module_python/actions/runs/42138496695

https://claude.ai/code/session_01FXHA3ZicrtZ4C5QPEgxfgq