metadata.internal boolean check rejects spec-compliant string value (blocks Rovo Dev / Agent Skills spec metadata: map[string]string)

Problem

The Agent Skills spec types metadata as "a map from string keys to string values" - every value under metadata must be a string. Atlassian's Rovo Dev CLI enforces that spec strictly with a Pydantic model (metadata: Dict[str, str]), so any repo whose SKILL.md sets metadata.internal: true (a YAML boolean) is entirely rejected by Rovo's skill loader:

Invalid skill definition in .../SKILL.md: 'metadata -> internal': Input should be a valid string

This isn't specific to the internal key - the same Pydantic error fires for any non-string metadata value (confirmed independently against a real, unrelated metadata.spaceCreation object value in another skill).

metadata.internal: true (boolean) is exactly what #119 shipped as the answer to "let me hide private/internal skills from skills add" discovery, and isInternal = metadata?.internal === true (in src/skills.ts, src/blob.ts, src/providers/wellknown.ts) is a strict boolean equality check. That leaves no representation that satisfies both ecosystems at once: a spec-compliant string value (e.g. metadata.internal: "true") fixes Rovo, but === true then reads as false for every one of those skills, so npx skills add/skills.sh's bulk/list/--all discovery permanently stops hiding them, with no env var or flag able to restore it.

Proposed Solution

Accept a string truthy value the same as the boolean, e.g. treat metadata.internal as internal when it is true (boolean, kept for compatibility) OR one of "true"/"1" (string), so a repo can be simultaneously spec-compliant for metadata: map[string]string]-typed consumers (Rovo Dev, and any other implementation that validates the open Agent Skills spec literally) and still hidden from skills add discovery.

Context

Hit this while making a public repo's .agents/skills/ (internal reference skills, kept metadata.internal: true per this project's own docs since #119 shipped) loadable by Rovo Dev; see kunchenguid/firstmate for the concrete repro and fix-side writeup once merged.