Summary

Fix Vigilante session log naming so logs remain unique across multiple watched repositories. Session logs are currently keyed only by issue number, which causes collisions when two repositories both have an issue with the same number. Log files should instead use a repository-qualified name such as {org}-{project}-issue-{number}.log.

Issue Type: bug

Problem

• Vigilante currently stores per-issue session logs using filenames like issue-123.log.
• That naming scheme is not safe once Vigilante is watching multiple repositories, because GitHub issue numbers are only unique within a repository, not across all watched repos.
• Two repositories with the same issue number can overwrite, reuse, or confuse each other’s local log files.
• This makes debugging harder, weakens auditability, and can break any workflow that assumes a session log maps cleanly to one repo issue.

Context

• The current collision point is in internal/state/state.go, where SessionLogPath(issueNumber int) returns ~/.vigilante/logs/issue-{number}.log.
• Vigilante already manages multiple repositories through the watchlist and daemon loop, so session-log storage must be repo-aware.
• Worktrees are already repo-local by filesystem path, which avoids this class of collision for code checkout state. The local logs directory does not currently have the same protection.
• The desired filename convention from the request is {org}-{project}-issue-{number} for the log basename, which aligns with the GitHub repo identity available to Vigilante.
• The issue is specifically about session log filenames and any direct callers or readers of those paths. It is not a request to redesign all state storage layout unless necessary to support the new naming safely.

Desired Outcome

• Session logs are named with repository-qualified filenames such as aliengiraffe-vigilante-issue-123.log instead of issue-123.log.
• Any code that creates, reads, tails, or references session log paths uses the repo-qualified naming consistently.
• Concurrent or historical sessions for different repositories with the same issue number no longer collide in ~/.vigilante/logs/.
• Existing daemon behavior and per-session logging continue to work without changing the operator-facing workflow.
• Non-goals:
• Do not change issue branch naming or worktree naming in this issue unless needed for consistency and explicitly justified.
• Do not introduce a larger logging backend or database migration beyond what is needed to remove filename collisions.

Implementation Notes

• Update the state/log path API so session log file naming includes repository identity, not only issue number.
• Prefer deriving the filename components from the GitHub repo slug already known to Vigilante, for example org/repo -> {org}-{repo}-issue-{number}.log.
• Sanitize filename components so the generated path is valid and predictable on supported platforms.
• Audit all call sites that currently depend on SessionLogPath(issueNumber int) and update them to pass enough repository context.
• Decide and document how to handle existing legacy log files:
• acceptable options include leaving old files in place and using the new naming for all new sessions
• or opportunistically migrating/renaming when safe
• This issue does not need a complex migration as long as the new behavior is correct and backward compatibility expectations are explicit.
• Avoid introducing ambiguity if the repository slug cannot be resolved; use the canonical repo identity Vigilante already tracks for watched sessions rather than guessing from directory names when possible.

Acceptance Criteria

• New session logs are written using the pattern {org}-{project}-issue-{number}.log or an equivalent sanitized form derived from the canonical GitHub repo slug.
• Two watched repositories that both process the same issue number produce distinct local log files.
• All current session-log readers/writers use the repo-qualified path consistently.
• Existing session execution, failure reporting, and daemon logging behavior remain unchanged apart from the session log filename.
• Legacy bare issue-{number}.log naming is no longer used for newly created session logs.
• The implementation handles invalid path characters in repository identity safely and deterministically.
• Relevant docs or code comments are updated anywhere the old filename shape is described or implied.

Testing Expectations

• Add or update unit tests around the state/log path helper to verify repo-qualified filenames and filename sanitization.
• Add or update tests covering two repositories with identical issue numbers to prove the generated log paths do not collide.
• Update any app/session tests that assert the old issue-{number}.log naming.
• Cover failure cases where repository metadata is missing or malformed enough to affect filename generation.

Operational / UX Considerations

• Keep log filenames human-readable so operators can still locate issue logs quickly in ~/.vigilante/logs/.
• Use a stable filename format so external tooling, support scripts, and future automation can rely on it.
• If legacy logs are left in place, avoid any behavior that makes old and new logs ambiguous to operators.