ebuild setup fails on first run — DEFAULT_CONFIG requests a branch neither repo has

[srpatcha]

ebuild setup is step 1 of the 8-command golden path. It fails for every new user.

Evidence

ebuild/deps/__init__.py ships this default:

DEFAULT_CONFIG = {
    "repos": {
        "eos":   {"url": DEFAULT_EOS_REPO_URL,   "branch": "main", "path": None},
        "eboot": {"url": DEFAULT_EBOOT_REPO_URL, "branch": "main", "path": None},
    },
    ...
}

manager.py:145 reads it (repo_cfg.get("branch") or "main") and _git_clone
passes it straight through:

cmd.extend(["--branch", branch, url, str(dest)])

Neither remote has that branch:

eos    default branch: master     has 'main'? 404 Branch not found
eBoot  default branch: master     has 'main'? 404 Branch not found

So the first command a new user runs does this:

$ git clone --depth 1 --branch main https://github.com/embeddedos-org/eos.git
fatal: Remote branch main not found in upstream origin
exit=128

_git_clone raises, cmd_setup catches and exits 1. Steps 2-8 of the golden
path are unreachable.

Why this was not noticed

It only reproduces on a machine with no ~/.ebuild/config.yaml. Once that file
exists — written by hand, or carried over from an older working checkout — its
branch: value wins over DEFAULT_CONFIG and every subsequent run succeeds
from cache.

I spent a while convinced this was fixed, because my own config says:

repos:
  eos:
    branch: master

A cold-cache run against that config clones fine and reports [ok] Setup complete. The failure is invisible to anyone who has ever had a working setup,
which is everyone who would be testing it.

Status

#64 fixes the instance, changing both defaults from main to master. That is
correct today and should merge.

It leaves the class open: the branch name is still a hardcoded guess in a
constant, checked by nothing. Renaming either repo's default branch to main —
an ordinary migration, and the direction GitHub defaults new repos to — brings
back exactly this failure, with the same invisibility.

Proposed follow-up, after #64

Stop guessing. Omitting --branch entirely makes git clone check out whatever
the remote's HEAD points at, which is the correct branch by definition and stays
correct across a rename:

• DEFAULT_CONFIG carries "branch": None, meaning the remote's default
• effective_branch = repo_cfg.get("branch"), dropping the or "main" fallback
• _git_clone appends --branch only when a branch was explicitly configured
• _checkout_branch returns early when no branch was configured

An explicitly configured branch keeps working and is still honoured. The
difference is that the default stops being a name someone has to remember to
update in two places.

A regression test should assert that no branch is requested when none is
configured, so the default cannot silently reacquire one.