Actual Account Deletion.

[DevOlabode]

Closes #82.

Functions:

• deletes account from vizably
• with permission deletes repo from users github account

[ieliofficial]

This one deletes people's repos so I want to be careful with it.

Two things:

First, the ordering. Wipe runs first, clears the session storage, then delete runs. If delete fails the user is left with their files gone, the repo still there, and no storage attached. And delete needs Administration: Read and write on the App, which is the same permission that's already failing for repo creation, see #86. So the likely outcome today is that the wipe succeeds and the delete 403s. Can we check that deletion is actually possible before wiping anything, or do the repo delete first?

Second, /account/delete-repository takes storageRef straight from the request body and passes it to repos.delete with no check that it's the repo the session had attached, or that it's a Vizably store at all. sameSite lax means it isn't remotely exploitable, so it's not urgent, but for something irreversible I'd rather it only delete the ref the session was holding.

Two smaller ones:

• _shouldFallbackToContentsApi now returns true for any 404, which will hide genuine missing repo or branch errors behind a second confusing failure
• the tree rebuild keeps only type === 'blob', so if someone attached us to an existing repo with a submodule, the wipe would quietly drop it from the tree

[DevOlabode]

On ordering: wipe-then-delete is bad if Administration isn’t there (same pain as #86). Better to ask both to confirm first. If they want the repo gone, delete it first; if that 403s, nothing’s been wiped yet. If they only want Vizably data gone, wipe and leave the repo.

On storageRef: agreed. Even with lax cookies, we shouldn’t delete whatever the client sends. Stick to the repo the session had attached (keep it on the session through the flow, or stash it server-side) and reject anything else.

I’ll fix both on this branch.

[ieliofficial]

I think you should be closing this, it's two features in one branch.

Delete account is deleting the repo, nothing else. No wipe step. Removing our files and leaving the repo behind isn't a state anyone wants, and it doesn't really erase anything anyway since the commits stay in history. One action, one confirm, danger zone in Account.

Delete scans is routine, so it goes in Dashboard next to the per-scan delete you built in #113. Checkboxes on the list, select all at the top, same confirm. Not a danger zone thing and not a Delete all button in settings, because that deletes things you can't see from where you're standing. Selection also gives you partial delete, which people want more often.

Keep from here: deleteGitHubRepository, the session-only storageRef, the Administration 403 message.
Drop: wipeAccountStore, /account/wipe, the two-step flow in AccountView.

Two issues instead of #82, one each. Take the repo delete first, it's nearly done.

If you reuse the mixed delete-plus-write handling for bulk delete, keep type === 'commit' entries in the tree rebuild or submodules get dropped.