docs: address second Copilot review on #716 — __init__.py + accurate git push behavior

Two valid Copilot findings:

1. **`__init__.py` missing from regeneration summary**: verified by
   reading `scripts/regenerate_client.py:347` — `move_client_to_workspace`
   writes a fixed flattened-import template to
   `katana_public_api_client/__init__.py` on every regen, overwriting
   whatever was there. The inline comment in the script says "preserve
   any custom content" but the code doesn't merge — it just writes the
   template. Added `__init__.py` to the rewritten-paths list with a
   parenthetical flagging the misleading comment so contributors don't
   put hand-maintained exports there expecting them to survive.

2. **Inaccurate `git push -u origin <branch>` rationale**: Copilot is
   right that `git push -u origin <branch-name>` with an explicit
   branch-name refspec creates/updates `refs/heads/<branch-name>` on
   the remote — it's safe by itself. The trap the rule guards against
   is under-specified pushes (bare `git push`, `git push -u origin`
   without a refspec, or commands routed by `push.default = upstream`)
   that resolve to the tracked upstream, which can be `main` if the
   branch was created via `git checkout -b <name> origin/main`.

   Reworded both the CONTRIBUTING walkthrough and the canonical
   COMMIT_STANDARDS "First-Push Safety" section so the rationale is
   technically accurate: the value of `HEAD:refs/heads/<name>` is
   removing dependence on `push.default`, branch-tracking config, and
   shell habits — not overriding refspec resolution that's already
   correct in the safe case. Kept the incident reference (commit
   `30f3fd86` reached main, tagged, and published before cancellation)
   in COMMIT_STANDARDS so the rule's history is preserved.

Refs #569.

Co-Authored-By: Claude <noreply@anthropic.com>

Author: dougborg

.github/agents/guides/shared/COMMIT_STANDARDS.md

@@ -301,21 +301,29 @@ commit anyway, so bundling is always the right call.
 ## First-Push Safety
 
 When a local branch was created via `git checkout -b <name> origin/main`, its upstream
-is set to `origin/main`. A subsequent `git push -u origin <name>` then resolves to its
-tracked upstream and **pushes the local tip straight to `main`** — bypassing PR review
-and triggering semantic-release.
+is set to `origin/main`. A subsequent under-specified push (bare `git push`, or
+`git push -u origin` with no refspec, or commands implicitly affected by
+`push.default = upstream`) can resolve to that tracked upstream and **push the local tip
+straight to `main`** — bypassing PR review and triggering semantic-release.
 
-**Always use the explicit destination ref for first-time pushes:**
+Even though `git push -u origin <branch-name>` with an explicit branch-name refspec *is*
+safe by itself, relying on it requires every contributor's git config and push habits to
+stay consistent forever. One stray `git config --global push.default upstream` or a
+muscle-memory bare `git push` is all it takes.
+
+**Always use the fully explicit destination ref for first-time pushes:**
 
 ```bash
-# Wrong — pushes to whatever the local branch tracks (may be main)
+# Risky — depends on push.default, branch tracking, and contributor habits
 git push -u origin chore/foo
 
-# Right — explicit destination, creates the remote branch
+# Safe — names both source (HEAD) and destination ref explicitly
 git push -u origin HEAD:refs/heads/chore/foo
 ```
 
-A `pre-push` hook enforces this; **do not bypass with `--no-verify`**.
+This actually happened: commit `30f3fd86` reached main + tagged `mcp-v0.44.1` +
+published to PyPI before the pipeline could be cancelled. A `pre-push` hook now enforces
+the explicit form on every contributor's machine; **do not bypass with `--no-verify`**.
 
 ## Multi-Package Changes
 

docs/CONTRIBUTING.md

@@ -122,17 +122,20 @@ All formatting is automated via `uv run poe format`.
 
 1. **Push to your fork** and create a pull request
 
-   For the first push of a new branch, use the explicit destination ref to avoid a bare
-   `git push -u origin <name>` resolving to the local branch's tracked upstream (which
-   may still be `main` if you created the branch via
-   `git checkout -b <name> origin/main`) and pushing your tip straight to `main`:
+   For the first push of a new branch, use the explicit destination ref so the push
+   doesn't depend on `push.default`, upstream-tracking config, or shell habits:
 
    ```bash
    git push -u origin HEAD:refs/heads/feat/your-feature-name
    ```
 
-   A pre-push hook enforces this; never bypass with `--no-verify`. Full rationale + the
-   incident that prompted the rule live in
+   The form `HEAD:refs/heads/<name>` names both the source (current HEAD) and the
+   destination ref explicitly, so it's immune to git configs (e.g.
+   `push.default = upstream`) that can reroute an under-specified push to whatever the
+   branch tracks — which, if you created the branch via
+   `git checkout -b <name> origin/main`, is `main`. A pre-push hook enforces the
+   explicit form; never bypass with `--no-verify`. Full rationale + the incident that
+   prompted the rule live in
    [COMMIT_STANDARDS "First-Push Safety"](../.github/agents/guides/shared/COMMIT_STANDARDS.md#first-push-safety).
 
 ### Commit Message Format
@@ -321,9 +324,11 @@ sync with the actual generators:
 If the docs and either script ever disagree, the script wins.
 
 The high-level rule: anything under `api/`, `models/`, `client.py`, `client_types.py`,
-`errors.py`, `py.typed`, and `models_pydantic/_generated/` (plus `_auto_registry.py`) is
-rewritten on every regen. Everything else under `katana_public_api_client/` (including
-the rest of `models_pydantic/` — hand-maintained pydantic infrastructure) is preserved.
+`errors.py`, `py.typed`, `__init__.py` (rewritten from a flattened-import template every
+regen — *not* preserved despite the inline comment in the script suggesting otherwise),
+and `models_pydantic/_generated/` (plus `_auto_registry.py`) is rewritten on every
+regen. Everything else under `katana_public_api_client/` (including the rest of
+`models_pydantic/` — hand-maintained pydantic infrastructure) is preserved.
 
 ### Regeneration Features