fix(providers): F-7 + F-10 + F-5 — provider-aware aliases, gh query, canopy issues

[ashmitb95]

Summary

Three related fixes from docs/test-findings.md. The headline is F-7 — provider-aware alias resolver (the test plan's P0). F-10 was found incidentally while smoke-testing F-5.

F-7 (P0) — canopy issue works for any provider

Before: canopy issue 5 against a github_issues provider failed with unknown_alias because the resolver was hardcoded to look for Linear-shaped IDs (SIN-412). M5 shipped the Provider Protocol but the alias-resolution layer above it never learned about non-Linear shapes.

After: every alias form works:

canopy issue 5                                 → ✓
canopy issue '#5'                              → ✓
canopy issue 'owner/repo#5'                    → ✓
canopy issue 'https://github.com/o/r/issues/5' → ✓  (URL extracted to canonical "o/r#5")
canopy issue SIN-412                           → ✓  (Linear path unchanged)
canopy issue auth-flow                         → ✓  (feature alias unchanged)

Design: new IssueProvider.parse_alias(alias) -> str | None Protocol method. Returns canonicalised id when the provider recognises the shape; None falls through to feature-lane lookup. LinearProvider.parse_alias matches [A-Z]+-\d+; GitHubIssuesProvider.parse_alias matches bare/hash/owner-repo/URL. resolve_linear_id renamed to resolve_issue_id (provider-aware); old name kept as deprecated wrapper that preserves the legacy no_linear_id error code for back-compat. The MCP issue_get tool now also routes through resolve_issue_id, so feature aliases work there too.

F-10 (incidental) — gh search issues query was malformed

Found while verifying F-5. GitHubIssuesProvider.list_my_issues built a query string like repo:owner/repo is:open assignee:@me and passed it positionally to gh search issues. But the search verb treats positional args as search text — the qualifiers got quoted as a single text token and the GitHub API returned Invalid search query.

Unit tests mocked _gh_json and asserted on constructed args, so they happily passed even though the args were nonsense to the real CLI. This is exactly the gap the integration test plan was meant to catch — and did.

Fix: switch to gh issue list --repo ... --state open --assignee @me --label ... (the right verb form, matches Phil's branch).

F-5 (P2) — canopy issues plural

Added cmd_issues mirroring mcp__canopy__issue_list_my_issues. Empty list when no provider configured. Both --json and human-readable rendering of canonical Issue shape.

Tests

+21 across:

• test_aliases.py — resolve_issue_id behaviour (Linear path, GH path with mocked provider, feature-lookup fallback, error codes); deprecated resolve_linear_id wrapper preserves legacy code.
• test_providers_linear.py — parse_alias matches Linear IDs only, returns None for GH-shaped / feature-name input.
• test_providers_github_issues.py — parse_alias matches bare/hash/owner-repo/URL; F-10 regression: list_my_issues uses gh issue list with the right flag set.
• test_providers_types.py + test_providers_registry.py — Protocol stubs gain parse_alias so isinstance(stub, IssueProvider) still passes.

Suite: 628 → 644 passing.

Test plan

• python -m pytest -q (644 pass)
• Manual against canopy-test with [issue_provider] = github_issues:
  • canopy issue 5, canopy issue '#5', canopy issue '<URL>' all return the canonical Issue shape
  • canopy issues --json returns [] (no assigned issues)
  • With one issue assigned: canopy issues renders #5 in_progress Test: ...

After this PR

Remaining from test-findings.md:

• F-3 (doctor mcp_orphans check + reaper) — backlog, separate PR.
• F-4 (docs/mcp.md OAuth-headless note) — small docs PR.