Use One GitHub Repository Per User

[DevOlabode]

Use a Dedicated GitHub Repository for Each Vizably User

Description

Summary

Update Vizably's GitHub storage architecture so that each user has a dedicated GitHub repository for storing their Vizably account data and scan results.

Problem

The current GitHub storage workflow needs to clearly define how repositories are associated with individual users. Using one dedicated repository per user provides a consistent and isolated storage location for each user's Vizably account and saved scans.

Proposed Work

• Create or assign one GitHub repository to each Vizably user.
• Associate the repository with the user's Vizably account.
• Store the user's vizably.json, scan index, and scan results in their dedicated repository.
• Prevent one user's account data from being stored in or accessed through another user's repository.
• Ensure the authentication and storage flow correctly identify the user's assigned repository.
• Handle repository creation and selection through the existing GitHub storage flow.
• Add automated tests covering repository-to-user association and access control.

Acceptance Criteria

• Each Vizably user has a dedicated GitHub repository.
• User storage is correctly associated with their account.
• Users cannot access another user's Vizably storage through the application.
• Scan results are saved to the user's assigned repository.
• Existing GitHub authentication and storage functionality continues to work.
• Automated tests verify the repository association and access behavior.

[ieliofficial]

Picking this up instead of #104. A few decisions first, then update the issue body to match and I'll take a look.

Vizably picks the location, the user doesn't. New stores are created as viz_scans, falling back to viz_scans-2, viz_scans-3 if taken.

Find the account by looking for a repo that contains vizably.json, never by matching the name. My own store is ieliofficial/vizably-scans with 9 scans in it, and a viz_* name match would lose it.

Discovery order, cheapest first: the storageRef already on the session, then a direct GET on the expected name so the normal case is one API call, then listing repos as a fallback. Only a device with no session gets to the third step.

Connect becomes one button. The repository name field and the "Use an existing repository" option both go. Right now that screen manages to show "Vizably account found, 9 saved scans" and "vizably-scans is TAKEN" at the same time, which is what this removes.

If discovery finds two stores, show a chooser. That's the only place a picker survives.

Keep the resolution logic provider-neutral so the Drive folder can reuse it in Phase 3.

Two things to leave out. We don't add our own permission checks, whoever can write to the repo owns the account, and GitHub's own permissions are the only thing deciding that. And no migration for existing stores, they keep working because discovery is manifest-based.

Also worth updating the two lines that currently point the other way: "handle repository creation and selection through the existing flow" keeps the picker, and "prevent one user's data being accessed through another's repository" implies we enforce something we don't.

Closes #99 and supersedes #104.