RBAC: validateSource blocks UI/REST member assignment on provider and configuration-created roles

## Bug

`validateSource` in `policies-validation.ts` enforces strict source matching on **all** role operations, including member assignment. Roles created by RBAC providers or `app-config.yaml` cannot have members added or removed via the Admin UI or REST API.

The `validateSource` comment states:

> "We are not strict for permission policies defined with an originating role source of configuration."

The code does not implement this exception — the check is strict for all sources.

## Steps to Reproduce

1. Create an RBAC provider that calls `connection.applyRoles()` — role is created with source matching the provider name
2. Open the RBAC Admin UI
3. Try to add a user or group to the provider-created role
4. Error: `Unable to edit role: source does not match originating role role:default/, consider making changes to the ''`

Same behavior for roles created via `permission.rbac.defaultPermissions` in `app-config.yaml` (source: `configuration`) and the built-in `role:default/rbac_admin`.

## Expected Behavior

The provider or configuration seeds the initial role state. After creation, the database is the source of truth — admins should be able to modify membership and permissions via the UI/REST API. The provider should use create-if-missing semantics, not overwrite admin changes on restart.

## Current Code

`policies-validation.ts`:
```typescript
if (roleMetadata.source !== source && roleMetadata.source !== 'legacy') {
return new Error(
`source does not match originating role ${roleMetadata.roleEntityRef}, consider making changes to the '${roleMetadata.source.toLocaleUpperCase()}'`,
);
}
```

`policies-rest-api.ts` (role PUT):
```typescript
err = await validateSource('rest', oldMetadata);
```

Hardcoded `'rest'` — rejects any role not originally created via REST.

## Proposed Fix

Allow REST/UI member assignment regardless of the role's originating source. The source check should guard against conflicting provider re-creation, not block admin day-to-day management.

## Environment

- `@backstage-community/plugin-rbac-backend`: 7.12.1 (also verified on 7.16.1 — identical behavior)
- `@backstage-community/plugin-rbac-node`: 1.23.0

Start in policies-validation.ts and follow the role PUT flow in policies-rest-api.ts, including the hardcoded 'rest' source passed to validateSource. Check the existing RBAC role and membership tests, then verify that UI/REST membership changes work for provider- and configuration-created roles without removing protection against conflicting provider role creation.

Written by the indexing model from the issue text.