fix(mcp): treat allowed-tools as a permission declaration for LP3

[CharmingGroot]

Fixes #15.

While reading the MCP least-privilege path I confirmed the reported false positive. LP3 flags standard-compliant skills, and the cause is a field-name mismatch between SkillSpector and the Agent Skills standard.

What this fixes

LP3 ("no declared permissions but code capabilities were detected") fired on skills that declare capabilities through allowed-tools, the field defined by the Agent Skills standard. Two things combined to cause it:

1. _parse_manifest only extracted permissions and dropped allowed-tools, so the field never reached the analyzer.
2. mcp_least_privilege only read permissions, so a skill declaring e.g. allowed-tools: [Bash, Read] was treated as having no declaration at all.

_parse_manifest now parses and preserves allowed-tools (both the list form [Bash, Read] and the comma-separated string form Bash, Read), and LP3 treats a non-empty allowed-tools as a valid declaration. LP1/LP4 continue to use the explicit permissions list only, so this change stays scoped to the LP3 false positive in the issue.

Scanning a skill that declares allowed-tools: [Bash, Read] with shell/file-read code no longer reports LP3.

Testing

• ruff check src/ tests/ and ruff format --check src/ tests/ pass.
• pytest -m 'not integration' passes (605 passed, 11 skipped). The integration suite needs an LLM endpoint and is unaffected.
• Added regression tests: allowed-tools parsing in build_context (list, comma-string, and malformed-value forms) and LP3 not firing when allowed-tools is declared. The existing "no declaration" test still asserts LP3 fires.