auth: stop forcing GIT_TERMINAL_PROMPT=0 on the credential subprocess

Issue #63 was about a public repo being prompted for a username and password because Resolve called the credential helper proactively. The right fix is the one that already shipped on this branch — defer Lookup until a real 401, so anonymous endpoints never reach the helper in the first place.

But on top of that, the original commit also forced GIT_TERMINAL_PROMPT=0 on every git credential subprocess. That was belt-and-suspenders, and the suspenders are the problem: a user with a configured helper that simply doesn't have an entry for a new host yet gets a 401 with no path to authenticate, because we explicitly disallowed git from falling through to a terminal prompt.

That matches neither vanilla git push behaviour nor user expectation: the first time you push to a new host, git prompts and the helper remembers the result. We blocked that flow entirely.

This change drops the override. The credential subprocess inherits the parent environment as-is:

• GIT_TERMINAL_PROMPT unset / "1": git may prompt on the controlling tty when the helper has nothing. Same as vanilla git.
• GIT_TERMINAL_PROMPT=0 in the caller's env: passed through. CI, daemons, and the syncer's background loop already set this (or should — same way they would for plain git) and continue to see clean non-blocking failures on missing credentials.

Doc updates on Lookup and the CredentialHelper interface to reflect that they MAY block on user interaction now, and how callers control that.

The previous regression test asserted the override was present; rewrote it as TestGitCredentialCmdInheritsEnvWithoutOverridingTerminalPrompt, which pins both directions (no entry when parent has none; pass-through when parent sets 0).