Add Droid host support for setup and skill generation

[Edmund-a7]

Summary

This adds first-class Droid host support to gstack.

What changed

• add --host droid to gen-skill-docs.ts
• generate Droid-formatted skills under repo-local .factory/skills/*
• update setup so ./setup --host droid:
  • installs runtime assets under ~/.factory/skills/gstack
  • links top-level slash-command skills into ~/.factory/skills/<skill-name>/
  • creates Droid reviewer droids for spec/design/code review
• replace the telemetry pending-marker glob with a find ... -print -quit check to avoid zsh no matches found failures
• add generator/setup regression tests for Droid output
• document Droid install flow in README and AGENTS.md

Why

Before this change, Droid could not reliably discover gstack slash-command skills such as /office-hours because:

• Droid-specific skills were generated into a nested layout that was not exposed as top-level skills
• setup --host droid linked ~/.factory/skills/gstack to the repo root, but did not link top-level skills like office-hours, review, or plan-ceo-review
• the telemetry preamble still used a shell glob that fails under zsh when no .pending-* files exist

This change makes Droid installation behave more like the existing Claude/Codex flows while preserving host-specific path rewrites.

Validation

Ran locally:

• bun run gen:skill-docs
• bun run gen:skill-docs --host codex
• bun run gen:skill-docs --host droid
• bun test test/gen-skill-docs.test.ts

[loocor]

Hi @Edmund-a7, I’m currently trying to think through how gstack should support more hosts without ending up with each runtime being handled as a separate special case ( #289 ), so this PR is very relevant to a problem I’ve been looking at.

What stood out to me here is that it surfaces several host-specific concerns very concretely: skill roots, generated output layout, top-level skill linking, and runtime asset setup all seem to vary in meaningful ways for Droid.

My current guess is that these differences may eventually want a more explicit abstraction layer, rather than being rediscovered host by host inside setup and gen-skill-docs.ts — but I may be missing Droid-specific constraints or tradeoffs here.

So I’m mostly commenting because this seems like a very useful real example for RFC #289, not because I think I already have the right answer. My hope is that work like this can help us identify the right shared shape for future host support, instead of each new runtime having to carve its own path independently.

If this resonates with how you’re thinking about Droid support, I’d really value your feedback. And if there are constraints here that make a more general adapter shape less practical than it sounds, that would also be very helpful to understand.