Private Repository Metadata Remains Accessible After Access Revocation

Affected: Go: code.gitea.io/gitea

### Summary

A user who previously had access to a private repository can continue to obtain repository metadata through `GET /api/v1/user/starred` after their access to the repository has been revoked.

After a collaborator is removed from a private repository, direct access to the repository is correctly denied. However, the repository may still appear in the user's starred repository list, and the endpoint continues to return repository metadata. Changes made to that metadata after access revocation are also reflected in subsequent responses.

### Details

The issue affects the authenticated endpoint:

```http GET /api/v1/user/starred ```

The same behavior was also observed on:

```http GET /api/v1/user/subscriptions ```

A reproducible scenario is:

1. User `alice` creates a private repository. 2. User `bob` is granted collaborator access. 3. `bob` stars the repository. 4. `alice` removes `bob` from the repository collaborators. 5. Direct repository access by `bob` is denied. 6. `bob` requests `/api/v1/user/starred`. 7. The repository is still present in the response together with repository metadata.

Additionally, if repository metadata is modified after access revocation, the updated values are returned by `/api/v1/user/starred`.

As a result, a user who no longer has permission to access the repository can continue to obtain repository metadata through the starred repository list.

### PoC

#### PoC Link https://anonymous.4open.science/r/Gitea_PoC-EC93/5_poc_starred…

Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um beliebigen Programmcode auszuführen, erweiterte Berechtigungen zu erlangen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren, sensible Informationen offenzulegen, Sitzungen zu übernehmen oder wiederzuverwenden oder einen Denial-of-Service-Zustand auszulösen.