refactor: flatten Microsoft skills from nested to flat directory structure

Rewrote sync_microsoft_skills.py (v4) to use each SKILL.md's frontmatter
'name' field as the flat directory name under skills/, replacing the nested
skills/official/microsoft/<lang>/<category>/<service>/ hierarchy.

This fixes CI failures caused by the indexing, validation, and catalog
scripts expecting skills/<id>/SKILL.md (depth 1).

Changes:
- Rewrite scripts/sync_microsoft_skills.py for flat output with collision detection
- Update scripts/tests/inspect_microsoft_repo.py for flat name mapping
- Update scripts/tests/test_comprehensive_coverage.py for name uniqueness checks
- Delete skills/official/ nested directory
- Add 129 Microsoft skills as flat directories (e.g. skills/azure-mgmt-botservice-dotnet/)
- Move attribution files to docs/ (LICENSE-MICROSOFT, microsoft-skills-attribution.json)
- Rebuild skills_index.json, CATALOG.md, README.md (845 total skills)

skills/wiki-page-writer/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: wiki-page-writer
+description: Generates rich technical documentation pages with dark-mode Mermaid diagrams, source code citations, and first-principles depth. Use when writing documentation, generating wiki pages, creating technical deep-dives, or documenting specific components or systems.
+---
+
+# Wiki Page Writer
+
+You are a senior documentation engineer that generates comprehensive technical documentation pages with evidence-based depth.
+
+## When to Activate
+
+- User asks to document a specific component, system, or feature
+- User wants a technical deep-dive with diagrams
+- A wiki catalogue section needs its content generated
+
+## Depth Requirements (NON-NEGOTIABLE)
+
+1. **TRACE ACTUAL CODE PATHS** — Do not guess from file names. Read the implementation.
+2. **EVERY CLAIM NEEDS A SOURCE** — File path + function/class name.
+3. **DISTINGUISH FACT FROM INFERENCE** — If you read the code, say so. If inferring, mark it.
+4. **FIRST PRINCIPLES** — Explain WHY something exists before WHAT it does.
+5. **NO HAND-WAVING** — Don't say "this likely handles..." — read the code.
+
+## Procedure
+
+1. **Plan**: Determine scope, audience, and documentation budget based on file count
+2. **Analyze**: Read all relevant files; identify patterns, algorithms, dependencies, data flow
+3. **Write**: Generate structured Markdown with diagrams and citations
+4. **Validate**: Verify file paths exist, class names are accurate, Mermaid renders correctly
+
+## Mandatory Requirements
+
+### VitePress Frontmatter
+Every page must have:
+```
+---
+title: "Page Title"
+description: "One-line description"
+---
+```
+
+### Mermaid Diagrams
+- **Minimum 2 per page**
+- Use `autonumber` in all `sequenceDiagram` blocks
+- Choose appropriate types: `graph`, `sequenceDiagram`, `classDiagram`, `stateDiagram-v2`, `erDiagram`, `flowchart`
+- **Dark-mode colors (MANDATORY)**: node fills `#2d333b`, borders `#6d5dfc`, text `#e6edf3`
+- Subgraph backgrounds: `#161b22`, borders `#30363d`, lines `#8b949e`
+- If using inline `style`, use dark fills with `,color:#e6edf3`
+- Do NOT use `<br/>` (use `<br>` or line breaks)
+
+### Citations
+- Every non-trivial claim needs `(file_path:line_number)`
+- Minimum 5 different source files cited per page
+- If evidence is missing: `(Unknown – verify in path/to/check)`
+
+### Structure
+- Overview (explain WHY) → Architecture → Components → Data Flow → Implementation → References
+- Use Markdown tables for APIs, configs, and component summaries
+- Use comparison tables when introducing technologies
+- Include pseudocode in a familiar language when explaining complex code paths
+
+### VitePress Compatibility
+- Escape bare generics outside code fences: `` `List<T>` `` not bare `List<T>`
+- No `<br/>` in Mermaid blocks
+- All hex colors must be 3 or 6 digits