Parent epic: #304

Problem

Tools declare grant categories as free-form strings: Grant = "shell", Grant = "filesystem", etc. The ACL system gates tool access on these strings. Nothing validates that a grant string matches a category the policy system actually recognizes. A typo like Grant = "shel" means the tool registers under a category no policy ever grants — effectively hiding the tool from all users.

Candidate rule

NCLW2003: Unknown tool grant category

• Trigger: [NetclawTool] attribute has a Grant value that doesn't match any entry in the known grant category set
• Severity: Warning
• Fix: Use a recognized grant category, or add the new category to the allowlist

Design considerations

The allowlist source needs to be maintainable. Options:

1. Constants class: A static class with const string fields (e.g., GrantCategories.Shell, GrantCategories.Filesystem) — analyzer checks against these values. This is also good API design since tool authors would use the constants instead of magic strings.
2. Attribute on assembly: [assembly: KnownGrantCategory("shell")] — more flexible, analyzable
3. Config file: .editorconfig or analyzer config — most flexible but harder to discover

Option 1 (constants class) is probably the right call since it also improves DX for tool authors.

Acceptance criteria

• Analyzer flags unknown grant category strings
• Known categories defined as constants (or equivalent discoverable source)
• Grant = "default" always passes (it's the fallback)
• Existing tools compile without new warnings