docs: bring docforge docstrings and wiki to GSDFC standard

- fix GSDFC spec contradictions in __init__ docstring (parenthesized types, fenced-block rule) and sync generated README
- rewrite docstrings across loaders, models, nav, servers, renderers, cli; sync .pyi stubs
- add pydoclint (google style) gate to dev extras and pyproject config
- fix mcp nav resources doc:// -> docs://
- refresh docs/lib and docs/mcp, drop stale docforge/ duplicate group
- update wiki pages and add GSDFC + MCP guides under 05_development

README.md

@@ -42,6 +42,18 @@ doc-forge build --mcp --module my_package
 doc-forge build --mcp --mkdocs --module my_package
 ```
 
+## Include a hand-written wiki in the MkDocs site:
+
+```bash
+doc-forge build --wiki --mkdocs --module my_package
+```
+
+## Build wiki pages only (no module required):
+
+```bash
+doc-forge build --wiki --site-name my_package
+```
+
 ## Serve MkDocs locally:
 
 ```bash
@@ -130,7 +142,9 @@ GSDFC defines how docstrings must be written so they render correctly in MkDocs
 
 - Use **Markdown headings** at package and module level.
 - Use **Google-style structured sections** at class, function, and method level.
-- Use type hints in signatures instead of duplicating types in prose.
+- Use type hints in signatures.
+- Use parenthesized types in prose entries (`name (Type):`) that match the
+  signature types. This keeps docstrings self-contained and machine-parseable.
 - Write summaries in imperative form.
 - Sections are separated by `---`
 
@@ -190,7 +204,10 @@ Example:
                 engine.run()
                 ```
 
-Avoid fenced code blocks inside structured sections.
+Avoid fenced code blocks inside argument descriptions and other prose lines.
+
+Inside `Example:` sections, fenced `python` code blocks are allowed and must be
+indented four spaces, matching the examples below.
 
 ---