Add a "generic agent" target architecture (no knowledge of specific internal tools)

Summary

Add a new "generic agent" target architecture to the Skill Builder (and ideally the Automation Builder) that has no knowledge of any specific internal tools. Selecting it should produce a portable, tool-agnostic SKILL.md that doesn't assume any single agent's native toolset.

Motivation

Today every target architecture is backed by a static capability catalogue of that agent's native/internal tools, and the builder deliberately generates a "native-tool-first" skill that prefers those tools:

• scout → workiq_*, browser, files, built-in skills (electron/skillbuilder/scout-catalog.ts)
• cowork → Teams/Outlook/Calendar/SharePoint, etc. (electron/skillbuilder/cowork-catalog.ts)

That's ideal when the destination agent is known, but it makes the output non-portable: a Scout- or Cowork-targeted skill references tools an arbitrary agent doesn't have. There's currently no way to record a task once and get a neutral skill you can hand to an unknown/third-party agent.

Proposed behavior

• New SkillArchitecture value, e.g. "generic", added to the enum and to ARCHITECTURES in common/skill.ts (enabled, with an explanatory note).
• Instead of an internal-tool catalogue, the generic target uses an empty/neutral capability catalogue: no workiq_*, no Scout/Cowork built-ins, no product-specific tool names.
• The builder generalizes steps in portable terms only — plain natural-language actions and, at most, universally-available primitives (shell, filesystem, HTTP/REST, a generic browser) — so any agent can execute it.
• catalogueFor("generic") must return a (neutral) catalogue so the builder gate in electron/skillbuilder/builder.ts ("That target architecture isn't available yet…") passes.

Scope / touch points

• common/skill.ts — enum + ARCHITECTURES selector metadata.
• electron/skillbuilder/ — new neutral generic-catalog.ts, wire into catalogueFor, plus a preamble/tail that explicitly forbids referencing product-specific tools.
• electron/automationbuilder/ — parallel support, or explicitly scope this issue to skills-only first (automations are Scout-only today).
• The renderer architecture selector should pick up the new enabled option automatically from ARCHITECTURES.

Acceptance criteria

• "Generic agent" appears as an enabled target in the architecture selector.
• Building a skill against it yields a SKILL.md with no product-specific internal tool names (e.g. no workiq_*, no Scout/Cowork built-in skill names).
• The generated steps remain runnable in principle by an agent that only has generic shell / browser / HTTP / file capabilities.
• Existing Scout and Cowork targets are unchanged.

Open questions

• Should "generic" permit a minimal common-denominator primitive set (shell/browser/HTTP/files), or be pure natural language with zero tool assumptions?
• Skills-only for v1, or include automations in the same change?

Start with common/skill.ts and trace catalogueFor plus the target-architecture gate in electron/skillbuilder/builder.ts. Add the neutral electron/skillbuilder/generic-catalog.ts integration and selector metadata, then check the renderer and any electron/automationbuilder paths. Done means Generic agent is enabled, generated SKILL.md output has no product-specific tool names, and Scout and Cowork behavior remains unchanged.