feat: add ignored_slash_commands setting to skip foreign-bot comments

[eg-ayoub]

Bert-E's reactor treats any comment starting with /word as a shorthand for one of its own commands, and posts an "UnknownCommand" reply when the keyword doesn't match a registered command. On pull requests shared with bots such as CodeRabbit, Gemini or GitHub Copilot, that behaviour produces noisy "unknown command" replies every time a user runs /coderabbit review, /gemini …, /copilot …, etc.

Add a new optional ignored_slash_commands list setting. When a comment starts with /<keyword> and <keyword> (case-insensitive) is on the list, the reactor drops the comment silently instead of dispatching.

The check applies only to the /… shorthand; comments that explicitly address Bert-E via its @<robot> mention are unaffected.

Backward-compatible: the marshmallow schema defaults the field to [], handle_comments reads it via settings.get(..., []), and the reactor methods default ignored_slash_commands to (), so existing settings files that never mention the option keep working unchanged.

Ticket: PTFE-3408

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.70%. Comparing base (6ddd9a5) to head (7422ee2).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #273      +/-   ##
==========================================
+ Coverage   89.62%   89.70%   +0.07%     
==========================================
  Files          81       81              
  Lines       10614    10680      +66     
==========================================
+ Hits         9513     9580      +67     
+ Misses       1101     1100       -1     

Flag	Coverage Δ
integration	87.16% <55.00%> (-0.07%)	⬇️
tests	87.12% <55.00%> (-0.07%)	⬇️
tests-BuildFailedTest	26.61% <20.00%> (-0.02%)	⬇️
tests-QuickTest	34.12% <20.00%> (-0.04%)	⬇️
tests-RepositoryTests	26.28% <20.00%> (-0.02%)	⬇️
tests-TaskQueueTests	51.31% <35.00%> (-0.05%)	⬇️
tests-TestBertE	65.48% <55.00%> (-0.02%)	⬇️
tests-TestQueueing	53.53% <30.00%> (-0.04%)	⬇️
tests-api-mock	15.24% <0.00%> (-0.10%)	⬇️
tests-noqueue	77.37% <55.00%> (-0.05%)	⬇️
tests-noqueue-BuildFailedTest	26.61% <20.00%> (-0.02%)	⬇️
tests-noqueue-QuickTest	34.12% <20.00%> (-0.04%)	⬇️
tests-noqueue-RepositoryTests	26.28% <20.00%> (-0.02%)	⬇️
tests-noqueue-TaskQueueTests	51.31% <35.00%> (-0.05%)	⬇️
tests-noqueue-TestBertE	61.88% <55.00%> (-0.01%)	⬇️
tests-noqueue-TestQueueing	26.30% <20.00%> (-0.02%)	⬇️
tests-server	28.09% <5.71%> (-0.15%)	⬇️
unittests	43.72% <95.71%> (+0.37%)	⬆️
utests	28.57% <95.71%> (+0.47%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[matthiasL-scality]

Design feedback

ignored_slash_commands: blocklist vs allowlist

The current approach requires administrators to maintain a blocklist of every foreign bot keyword — a list that will inevitably grow stale as new AI tools enter the workflow (Devin, new Copilot commands, etc.).

An allowlist feels more maintainable and logically sounder: Bert-E already has an internal registry of its own recognised commands (via @reactor.command). Any /keyword shorthand that does not match a registered command could simply be dropped silently, with zero configuration required.

The main tradeoff to weigh: a user who mistypes /apporve would no longer receive an "unknown command" reply. That regression can be mitigated by convention — the explicit @<robot> approve form always goes through the full dispatch path and would still produce feedback.

Worth discussing whether that trade is acceptable before the setting lands in production configs.

---

bypass_author_approval should be a separate PR

The change in integration.py (making bypass_author_approval trigger integration-branch creation) and the corresponding test additions are independent of the slash-command filtering feature. Bundling them means both changes ship in the same release, which makes changelogs harder to read and rollbacks harder to scope. Please consider splitting it into its own PR so the two fixes can be released and reverted independently.

[eg-ayoub]

ok @matthiasL-scality I will first split this into two PRs and we'll look at them separately.

[eg-ayoub]

@matthiasL-scality this is the offshoot PR #274 for the approve issue