[BUG] Improve sweep.yaml comment trigger

[wwzeng1]

What does this implement/fix? Explain your changes.

This improves the sweep.yaml comment.

Does your contribution introduce a new dependency? If yes, which one?

NA

PR checklist

For all contributions

• I've added myself to the list of contributors.
  Alternatively, you can use the @all-contributors
  bot to do this for you.
• The PR title starts with either [ENH], [MNT], [DOC], [BUG] or [GOV] indicating
  whether the PR topic is related to enhancement, maintenance, documentation, bugs or
  governance.

For new estimators and functions

• I've added the estimator to the online API documentation.

For developers with write access

• Optionally, I've updated aeon's CODEOWNERS
  to receive notifications about future changes to these files.

[wwzeng1]

@all-contributors please add @wwzeng1 for bug

[allcontributors]

@wwzeng1

I couldn't determine any contributions to add, did you specify any contributions?
Please make sure to use valid contribution names.

[github-actions]

Thank you for contributing to aeon!

I have added the following labels to this PR based on the title: [ $\color{#d73a4a}{\textsf{bug}}$ ].

The "Checks" tab above or the panel below will show the status of our automated tests. From the panel below you can click on "Details" to the right of the check to see more information if there is a failure. If our pre-commit code quality check fails, any trivial fixes will automatically be pushed to your PR.

Don't hesitate to ask questions on the aeon Slack channel if you have any!

[wwzeng1]

https://github.com/all-contributors please add @wwzeng1 for bug

[sweep-ai]

Apply Sweep Rules to your PR?

• Apply: There should not be large chunks of code that are just commented out. Docstrings and explanations in code are okay though.
• Apply: Any clearly inefficient or redundant code can be optimized or refactored. Any improvements should not change the functionality of the code.
• Apply: All public classes and functions should have a numpydoc style docstring. This should include a description of the class or function, the parameters, the class attributes or function return values, and a usage example for the class or function.
• Apply: Update the relevant API page in 'docs/api_reference/' when new public functions and classes are added and not included in the API documentation. For example, if a new function is added to 'aeon/distances/', a sphinx.ext.autosummary link should also be added to 'docs/api_reference/distances.rst'. New sections in the page should not be created for individual functions and classes, add it to the most relevant existing one. Only add functions and classes which are not already in the relevant API page and avoid duplicate entries.
• Apply: We use unit tests for our code. If we have 'class.py', there can be a 'tests/test_class.py' relative to the directory of the file. It is not necessary to create a test file for each new class and function, but any file specific tests should be in similarly named file.

[MatthewMiddlehurst]

@all-contributors please add @wwzeng1 for fixing a bug

[allcontributors]

@MatthewMiddlehurst

I've put up a pull request to add @wwzeng1! 🎉

[MatthewMiddlehurst]

I dont know why it liked mine and not yours. Thanks for this, lets hope this is better.

[MatthewMiddlehurst]

I'm going to piggy-back off this to remove the test rule also actually, I think it is too lax as well and not every file needs one really.