Adopt pkc-js exclude.publicKeys / names / roles; exclude.address and exclude.role are removed

[Rinse12]

Upstream change

pkc-js removes the challenge exclude field exclude.address (pkcprotocol/pkc-js#267, PR pkcprotocol/pkc-js#294). It matched the runtime author.address, which is name || signerAddress built from the unresolved wire name, so a signer could match an owner/mod exclude keyed on a domain it does not own.

It is replaced by two explicit fields on community.settings.challenges[].exclude[] (and mirrored on the public community.challenges[].exclude[]):

• publicKeys: string[] - key-derived author addresses (12D3Koo...), matched against the publication signature
• names: string[] - author domains (user.bso, user.eth), resolved by the community at match time and required to resolve to the signer, regardless of resolveAuthorNames

exclude.address is rejected by the schema (ERR_CHALLENGE_EXCLUDE_ADDRESS_FIELD_REMOVED), so a community.edit() that still sends it fails. Existing private settings are migrated automatically by the community owner node at DB version 42 (the old array is split by kind). The roles map keys are unchanged.

What needs to change here

src/views/community-settings/challenge-settings/challenge-settings.tsx reads and writes exclude.address (handleExcludeAddress, handleExcludeChange(excludeIndex, 'address', ...), the read-only display of exclude?.address). After the pkc-js upgrade:

• editing any challenge settings will fail schema validation if the exclude object still carries address
• the read-only view will show nothing for excludes written in the new shape

Suggested: replace the single "addresses" input with either two inputs (public keys / names) or one input that splits entries by whether they look like a domain, writing publicKeys and names and never address. Display both fields in read-only mode.

Update: the exclude role field is also renamed: exclude.role -> exclude.roles. Every array-valued exclude field is now plural (publicKeys, names, roles, challenges). Anything that writes exclude.role (e.g. the default mod exclude { role: ['moderator', 'admin', 'owner'] }) must write roles, and read-only views should read roles. Migration of stored settings happens on the community owner node at DB version 42.