Challenge exclude by author address is resolver-dependent when the address is a domain

[Rinse12]

Problem

shouldExcludePublication() matches an exclude's address list against publication.author.address by string equality (src/runtime/node/community/challenges/exclude/exclude.ts, the exclude.address && !exclude.address.includes(author.address) branch).

author.address is a runtime value computed as name || publicKey. When the author has a domain, it is the domain, and the domain only becomes the address after the community resolves the text record and confirms it points at the signer (src/runtime/node/community/local-community/publication-validation.ts, the author-identity checks). Publications whose author domain cannot be resolved are rejected outright.

So an exclude configured with a domain address has a runtime dependency on name resolution:

• while the resolver (or its RPC provider) is down, publications from that author are rejected before the exclude is ever consulted, so a whitelist keyed on the domain silently stops working;
• the failure mode is a hard reject rather than a fallback, which is correct for identity but surprising for an operator who configured a whitelist.

Why it matters now

The author-communities design (issue #31, docs/protocol/author-communities.md) enforces owner-only top-level posting with a seeded fail challenge plus an owner-address exclude. If that exclude is seeded with the owner's domain, a resolver outage locks the owner out of posting to their own profile. The design should seed the publicKey-derived address instead, but the general problem is broader than author-communities.

Options

1. Document that exclude.address should be given publicKey-derived addresses when availability matters, and seed author-community defaults that way.
2. Match an exclude entry against both the domain and the signer-derived address, so a whitelist keeps working when resolution is unavailable.
3. Add an explicit exclude.publicKey field, making the signature-backed identity the first-class way to whitelist.

Option 2 or 3 removes the operational footgun; option 1 alone leaves it in place for anyone who configures a domain by hand.

Scope

Separate from the author-communities design PR. Affects normal communities equally.