Fix/243 truncated repo tree fallback

[envico801]

Fix: Handle GitHub API tree truncation (100k+ files)

This PR fixes an issue where repository sizes are not displayed (or show "...") for very large repositories.

Root cause

The extension relies on the GitHub API endpoint:

/repos/:owner/:repo/git/trees/:sha?recursive=1

However, GitHub enforces a hard limit of 100,000 files per response. When this limit is exceeded:

• The response is truncated (truncated: true)
• Large portions of the repository tree are missing
• Certain directories (depending on alphabetical order) are never returned

Check the official api for more info:

• REST API endpoints for Git trees
• REST API endpoints for repository contents

As a result, the extension fails to find files and outputs "...".

This can be reproduced with:

• https://github.com/McTavishLab/AvesData/tree/cf49a8c5379d6aab19ab24738c0e968e723d9416/Tree_versions/Aves_1.5/Clements2023

---

Solution

When a truncated tree is detected, this PR introduces a fallback mechanism:

• Detect repoInfo.truncated === true

• Fetch the currently viewed directory using:

  /repos/:owner/:repo/contents/:path
  

• Inject the returned items into the existing tree

This ensures that visible files in the current directory always have valid size data.

---

Limitation (Important)

• Folder sizes may appear as 0 B in truncated repositories

This is expected, since calculating folder sizes would require recursive fetching, which would:

• Significantly increase API usage
• Potentially freeze the extension on very large repositories

---

Changes

• Added getFallbackDirectoryInfo() in api.ts
• Integrated fallback logic in updateDOM() in dom-manipulation.ts

---

Closes #243

Before:

After: