docs(git): delete unused git plugin config file and its read steps

Finding 21: `config.example.json` (and the never-tracked
`.claude/plugins/git/config.json` it documented) was read by
git-orchestrate and git-branches but written by nothing, and the
default-inference fallback (GitHub Flow, with Gitflow inferred from a
`develop`/`release/*` branch) already covered the no-config case.
Removed the config-read step from both, updated git-workflow's
description of the orchestrator to match, dropped the now-dangling
`applied_config` field from git-orchestrate's output shape, and
deleted the config file and its stale example reference in
docs/spec/architecture.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YR2CjVumUbEGWcMikcoXBD

plugins/git/skills/git-branches/SKILL.md

@@ -9,7 +9,7 @@ description: >
   Not a Gitea remote's branches -> `gitea-branches`.
 
 metadata:
-  version: "1.0.2"
+  version: "1.0.3"
   category: git
   source_keys:
     - context7-git-htmldocs
@@ -26,7 +26,7 @@ metadata:
 
 ## Step 1 — Determine the branching pattern
 
-Read `branching_pattern` from the git plugin config (`.claude/plugins/git/config.json`; the plugin root's `config.example.json` shows the shape). Default: `github-flow`. With no config, infer Gitflow from the presence of a `develop` or `release/*` branch, and GitHub Flow otherwise.
+Infer the branching pattern from the repo: Gitflow if a `develop` or `release/*` branch exists, GitHub Flow otherwise (the default).
 
 The two patterns are not mixable, and the wrong merge rule silently damages history. If the action touches a base branch, a name prefix, or a merge rule, read `references/branch-patterns.md`.
 

plugins/git/skills/git-workflow/SKILL.md

@@ -8,7 +8,7 @@ description: >
   agent caller -> `git-orchestrate`. Not Gitea -> `gitea-workflow`.
 
 metadata:
-  version: "1.0.0"
+  version: "1.0.1"
   category: git
   source_keys:
     - nvie-gitflow-post
@@ -55,8 +55,8 @@ owns the request.
    touches hooks, config, or credentials, read `references/hard-rules.md`. Raise the relevant rule
    before acting, not after.
 3. **Read the repo** — current branch, working-tree state, and which branching model the repo
-   follows (the orchestrator reads `branching_pattern` from plugin config; infer from branch names
-   if absent); the last of those decides which tips are worth offering.
+   follows (`git-branches` infers this from branch names: Gitflow if `develop`/`release/*` exists,
+   GitHub Flow otherwise); the last of those decides which tips are worth offering.
 4. **Gate destructive operations** — before force-push, branch deletion, rebase, or
    force-checkout, show what will happen and ask "Proceed?". Cancel gracefully if the user
    declines. Never supply the confirmation on the user's behalf. Some operations are refusals, not