fix: two-step EMU repo visibility change for create and settings update

[Copilot]

GitHub's template generation API has no visibility: 'internal' parameter — only private: true/false. EMU orgs also reject private: false (public) on PATCH. Both the creation and settings-update paths need explicit handling.

Changes

POST /api/projects/[projectName] (creation)

• createRepositoryFromTemplate already sets private: true when repoVisibility === 'internal' (template API limitation)
• Added clarifying comment explaining the two-step sequence: create private → PATCH to internal

PUT /api/projects/[projectName] (settings update)

• Bug: toggling is_private from true → false sent { private: false }, which attempts a public visibility change that fails on EMU orgs
• Fix: detect enterprise context and use 'internal' as the target visibility instead:

const isEnterprise =
  isEnterpriseGitHubOrg(slugContents.org) ||
  cookies.get('auth-provider')?.value === 'utexas';
const targetVisibility: boolean | 'internal' =
  !body.is_private && isEnterprise ? 'internal' : body.is_private;

Enterprise is detected via GITHUB_ENTERPRISE_ORGS env var or the auth-provider=utexas cookie set during UTexas EMU OAuth.

[saracarl]

@copilot When we test this, we get a "The repository was not successfully created." even though the repo was created. It was created was "private" with no change to "internal" I wonder if the code is trying to create the repository twice instead of updating the visibility.