feat(storage): add storage_path column to repository

[trenysx]

Add a storage_path column to the repository table storing the relative path of the repository on disk - the foundation for sub-group support (#1872).

An empty value keeps the legacy lower(owner)/lower(name).git convention, so existing repositories and all current behavior are unaffected. Only code repositories with a set value resolve to the custom location.

Covered by unit tests: migration idempotency and path resolution.

[trenysx]

Hi maintainers - this is the first of a small chain of PRs to introduce stable storage_path support for repositories (foundation for the disk-locating work referenced by #1872). CI is green on SQLite/MySQL/PG/MSSQL. No rush, just keeping it on the radar.\n--\ntrenysx\nAssisted-by: opencode:deepseek-v4-flash-free

[wxiaoguang]

Describe your design, how "StoragePath" works in various cases.

1. Convert all old paths to the new layout
2. Owner rename
3. Repo rename
4. Repo adopt
5. Repo transfer

By the way, the internal storage path should be "fixed", e.g.: UUID. It should never change even if the repo/owner is renamed or transferred.

---

If a new "feature" is introduced, it should at least be used somewhere, but not just add a dummy field.

[trenysx]

Thanks for the review. You're right on all counts.

Honest status of the five cases:

1. Convert old paths - not implemented (column defaults to empty, no backfill)
2. Owner rename - not handled
3. Repo rename - handled in fix(storage): honor storage path on repo transfer and rename #38962 (changeRepositoryName keeps custom path)
4. Repo adopt - not handled
5. Repo transfer - handled in fix(storage): honor storage path on repo transfer and rename #38962 (transferOwnership keeps custom path, tested)

I agree the internal path should be immutable (repo-ID/UUID) and that a bare column isn't a feature by itself. Since 3 of 5 cases are still open, I'll close this PR and the storage_path work here - it's not ready for merge. Thanks for the clear guidance.