skilltoolset: SKILL.md frontmatter with a key outside the spec set fails to parse (KnownFields), unlike adk-python #1957

🔴 Required Information

Describe the Bug:
tool/skilltoolset/skill.Parse decodes the SKILL.md frontmatter with yaml.Decoder.KnownFields(true) into a struct that knows only the agentskills.io keys (name, description, license, compatibility, metadata, allowed-tools) — tool/skilltoolset/skill/frontmatter.go:170 on main (733b525). Any other top-level key fails the parse. The strict decode dates from the package's first commit (090cbe5, #693) and no later change discusses it.

Skills are routinely shared between agent runtimes, and other runtimes put their own keys at the top level: Claude Code skills carry user-invocable and argument-hint, many authors add a plain version:. Such a SKILL.md cannot be loaded by ADK Go at all.

This diverges from adk-python, whose Frontmatter is ConfigDict(extra="allow") (src/google/adk/skills/models.py), so the same skill loads there. CONTRIBUTING.md names adk-python as the source of truth for validation.

Steps to Reproduce:

1. Write skills/shared-skill/SKILL.md:

   ---
   name: shared-skill
   description: A skill shared with another agent runtime.
   user-invocable: true
   ---
   # Instructions

2. skill.NewFileSystemSource(os.DirFS("skills")).ListFrontmatters(ctx) (or skilltoolset.New with that source).
3. Observe the error.

Expected Behavior:
The skill loads; keys outside the specification set are ignored, as in adk-python.

Observed Behavior:

parse frontmatter: yaml: unmarshal errors:
  line 4: field user-invocable not found in type skill.frontmatterYAML

fileSystemSource.ListFrontmatters returns that error for the first such skill (filesystem_source.go:55-73), so one skill with an extra key makes the whole skilltoolset fail to construct.

Environment Details:

• ADK Library Version: v2.6.0 (and main at 733b525)
• OS: Linux
• Go Version: 1.26

Model Information:

• N/A (parsing only)

🟡 Optional Information

Regression: No; present since the package was introduced in #693.

Spec context: The Agent Skills specification lists name and description as required and license, compatibility, metadata, allowed-tools as optional. On metadata it says: "Arbitrary key-value mapping for additional metadata" and "Clients can use this to store additional properties not defined by the Agent Skills spec." It has no sentence on unknown top-level keys. The reference skills-ref validate rejects them, but that is an authoring lint; adk-python, the loader this project follows, accepts them.

Proposed fix: drop KnownFields(true) and keep every other check (required fields, name rules, allowed-tools grammar). One known trade-off: a misspelled known key (descripton, licence) is then ignored instead of reported, which is what adk-python does today; skills-ref validate remains the place to catch typos at authoring time. PR follows, it is the minimal change under either answer to the question below.

Related question: ListFrontmatters stops at the first SKILL.md that fails to parse, so one malformed skill removes every skill from the agent. Would you take per-skill tolerance (skip the skill, report it) as a separate change, or is fail-fast intended?

How often has this issue occurred?: Always (100%) for any SKILL.md with a key outside the set.