feat: add workflow-purge skill and fix launcher eventType bitmask

[akankshajain18]

• Add workflow-purge/SKILL.md covering Purge Scheduler OSGi config, retention policies, bloat recovery, RUNNING/SUSPENDED cleanup, and Cloud Manager log monitoring
• Add workflow-purge to orchestrator routing table, skill map, and reference loading order
• Expand launcher eventType table to full 6-value bitmask with combined-value lookup (3, 7, 18, 26)
• Add Launcher Loop Prevention section with excludeList, glob, and conditions strategies
• Fix excludeList description in launcher-config-reference.md to correctly document its loop-prevention role

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[rombert]

Thanks for the PR @akankshajain18 . Can you please add more context around the admin/admin changes? To me it looks like it would prevent the dev/localhost scenario from functioning. It would be good to understand the kind of interactive experience you envision for providing credentials.

[rombert]

@akankshajain18 - please target this PR to main. We already merged the beta branch and this way you'll also get the PR checks running.

[akankshajain18]

Thanks for the PR @akankshajain18 . Can you please add more context around the admin/admin changes? To me it looks like it would prevent the dev/localhost scenario from functioning. It would be good to understand the kind of interactive experience you envision for providing credentials.

I wanted to keep the command more generic and avoid hardcoding credentials like admin:admin in the example. Even though those default credentials are commonly known and may not pose a significant risk in a local/dev setup, explicitly exposing usernames and passwords in commands or documentation is generally not a good practice.

The intention wasn’t to break or complicate the dev/localhost workflow, but rather to encourage providing credentials in a safer and more flexible way.

[rombert]

Thanks @akankshajain18 . I think the general direction makes sense. What I would suggest is to remove the note to 'never use default credentials' because I don't see any harm in that and document that unless credentials are provided to use 'admin:admin'.

---

In the end, I wonder if the -u username:password argument is really needed or the agent will figure out what to us; but it's up to you if you want to check that route.

I'm fine with merging with the minimal addition I suggested above (or something equivalent).

[rombert]

Oh, one more thing @akankshajain18 - please create the PR from a branch of this repository as we need that for the additional PR checks to run.