Handle transient 404 on organization repository-defaults during first import

[Copilot]

First-time otterdog import for newly created organizations could fail when GitHub temporarily returned 404 for the settings/repository-defaults page; a subsequent import usually succeeded once the page became available. This change makes that path resilient to the transient availability window without relaxing failures for other pages.

• Web UI page-load resilience

  • Updated WebClient._goto(...) to retry only when:
    • status is 404, and
    • URL targets .../settings/repository-defaults.
  • Retries are bounded and delayed; non-404 errors and non-target pages still fail immediately.

• Behavioral guardrails

  • Kept existing error semantics for all other page loads.
  • Scoped retry logic narrowly to avoid masking unrelated failures.

• Focused test coverage

  • Added tests/providers/github/test_web_client.py with explicit cases for:
    • retry + eventual success on repository-defaults,
    • no retry for 404 on unrelated settings pages.

if status == 404 and url.endswith(self._REPO_DEFAULTS_PAGE_URL) and retry_idx < max_retries:
    await sleep(self._REPO_DEFAULTS_404_RETRY_DELAY)
    continue
raise RuntimeError(f"unable to load github page '{url}': {status}")

[mbarbero]

cc @heurtematte

[heurtematte]

Sounds more like a workaround than a root cause fix. This happened to me twice in a row for two GitHub organizations.

[mbarbero]

Sounds more like a workaround than a root cause fix. This happened to me twice in a row for two GitHub organizations.

Those orgs were both brand new?

[heurtematte]

that's right!