fix(ci): raise the 55m unit-shard job timeouts to the 60m the startup gate requires

[oneKn8]

TLDR

Problem this solves:

• code-quality fails on every PR opened since perf(ci): give the two longest unit shards the runner's spare cores #37804 landed
• Three unit shards cap the job at 55m while their budgets need 60m

How it solves it:

• Raises the three job-timeout-minutes: 55 entries to 60
• check_workflow_startup_safety.py passes again

User Flow

Before: every contributor's PR shows a failing required-adjacent check they cannot fix

1. They open any PR against litellm_internal_staging
2. Code Quality Checks / code-quality fails after ~1m with "job unit gives pytest 20m but caps the job at 55m ... raise job-timeout-minutes to at least 60", three times
3. The failure names .github/workflows/test-unit.yml, a file their PR does not touch

After: the same PR runs code-quality green

1. They open any PR against litellm_internal_staging
2. Code Quality Checks / code-quality passes

Relevant issues

Regression from #37804 (the two resized shards, plus enterprise-package, kept a 55m cap). Every open PR created after it shows the same red, e.g. #38047, #38048, #38049, #38051, #38053.

Pre-Submission checklist

• I have added meaningful tests (no new test: the invariant is already enforced by tests/code_coverage_tests/check_workflow_startup_safety.py, which this change turns green)
• The check covering this change passes locally: uv run python ./tests/code_coverage_tests/check_workflow_startup_safety.py prints "Workflow startup invariants hold (setup ceiling 35m)"
• My PR passes all required CI/CD checks
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review

Screenshots / Proof of Fix

CI-only change; the proof is the gate itself.

Before (d1f3778, staging HEAD)

$ uv run python ./tests/code_coverage_tests/check_workflow_startup_safety.py
ERROR: Workflow startup invariants violated:
  - .github/workflows/test-unit.yml: job `unit` gives pytest 20m but caps the job at 55m. Setup can use up to 35m plus 5m of runner overhead, so the job deadline would preempt pytest; raise job-timeout-minutes to at least 60.
  (x3)

After (this PR)

$ uv run python ./tests/code_coverage_tests/check_workflow_startup_safety.py
Workflow startup invariants hold (setup ceiling 35m)

[greptile-apps]

Greptile Summary

Raises the job timeout from 55 to 60 minutes for three unit-test shards so their 20-minute test budgets fit behind the shared workflow’s 35-minute setup ceiling and 5-minute runner allowance.

• Updates the caching-local, proxy-extras, and enterprise-package shard deadlines.
• Restores compliance with the existing workflow startup-safety check.

Confidence Score: 5/5

The PR appears safe to merge because all three timeout changes satisfy the existing startup-safety invariant without altering test selection or execution behavior.

The affected shards each retain a 20-minute pytest budget and now receive the required 60-minute job deadline, matching the reusable workflow contract and established sibling configuration.

Important Files Changed

Filename	Overview
.github/workflows/test-unit.yml	The three timeout increases match the reusable workflow’s documented minimum and introduce no actionable issue.

_{Reviews (1): Last reviewed commit: "fix(ci): raise the 55m unit-shard job ti..." | Re-trigger Greptile}

[oneKn8]

The build-ui red here is a second staging-side break, unrelated to this timeout change: the #33514 merge reintroduced CheckOutlined/CopyOutlined after #37553's lucide swap, so the dashboard fails to type check at skill_detail.tsx:346 on current staging. One-line fix in #38103.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[oneKn8]

Superseded by #38139, which landed the same 55m to 60m change on staging. Closing.