feat: classify dirty state for submodule-heavy monorepos

[jacobleft]

🔎 Existing issue check

• I have searched the existing issues.

🧭 Problem

In a Julia monorepo with many git submodules, Comet/OpenSpec archive and commit phases had to work around unrelated dirty submodule state. Parent git status --short --branch showed both current workflow changes and unrelated submodule dirt, e.g.:

 M RibleANCF
 m RibleUniCableRobots
?? openspec/changes/...

The correct action was to stage current OpenSpec/Comet files and the relevant submodule pointer while leaving unrelated submodule dirt untouched. This classification was manual.

✨ Proposed solution

Comet should classify dirty state into categories such as:

• parent tracked files owned by current change
• OpenSpec/Superpowers artifacts owned by current change
• current-change submodule pointer updates
• dirty work inside current-change submodules
• unrelated dirty submodules
• untracked unrelated files

The guard/status output should recommend safe staging commands or explicitly say which dirty entries are ignored as unrelated.

🎯 Primary area

Classic workflow runtime (domains/comet-classic, assets/skills/comet/scripts/)

🪐 Workflow phase

Build

🔀 Alternatives considered

Use a generic dirty-worktree warning and rely on the agent to manually inspect submodule status. This is risky because staging the wrong submodule pointer can capture unrelated work, while blocking on every dirty submodule prevents valid archive/commit flows.

🧰 Compatibility notes

• Comet package: @rpamis/comet@0.4.0-beta.3
• Repo shape: Julia monorepo with multiple git submodules
• Relevant commands: git status --porcelain=v1, git submodule status, parent git diff --submodule

🧩 Additional context

Suggested regression test: parent repo with at least two submodules, one related to the current change and one unrelated dirty submodule.