Fix: Role model should use composite primary key (name, project)

[cuixiaojun001]

Description of your changes

Fixes #936

The Role model was missing gorm:"primaryKey" on its Project field, so the vela_role table only enforced uniqueness on the name column under the SQL (MySQL/PostgreSQL) datastore. This contradicts the intended composite key of (name, project) and causes project-scoped roles with the same name (project-admin / app-developer / project-viewer, seeded for each project) to collide at the SQL level: the second project's insert is silently skipped by BatchAdd and ends up referencing another project's role row.

This PR adds gorm:"primaryKey" to Role.Project to align with the sibling Permission model (which already uses this composite key) and with the logic already encoded in Role.PrimaryKey() and the kubeapi backend's ConfigMap naming.

I have:

• Read and followed KubeVela's contribution process.
• Related Docs updated properly. In a new feature or configuration option, an update to the documentation is necessary. (N/A — bug fix, no API/config change)
• Run yarn lint to ensure the frontend changes are ready for review. (N/A — no frontend change)
• Run make reviewable to ensure the server changes are ready for review.
• Added backport release-x.y labels to auto-backport this PR if necessary.

Special notes for your reviewer

• This fix only affects schema generation (GORM AutoMigrate); it takes effect for fresh deployments. Existing MySQL/PostgreSQL deployments need a manual DDL migration:

  ALTER TABLE vela_role DROP PRIMARY KEY, ADD PRIMARY KEY (name, project);

• The kubeapi datastore backend is unaffected; the inconsistency only manifests on MySQL/PostgreSQL.