content_filter: contains operator does exact equality, and author rules would break across networks #27

Two problems in evaluateRule (content_filter.go:502). Neither is reachable today, so nothing is broken for users right now, but both will bite whoever wires up a rule editor.

First, contains is implemented as == for both category and author (:525 and :533). A rule using that operator behaves exactly like eq.

Second, an author rule compares app.Author against a value the user typed in. For a TELA app the stored author came from the DVM, which always renders dero1 even on the simulator, because ADDRESS_STRING builds the string through rpc.NewAddressFromKeys and leaves Mainnet true. A user on the simulator copies their address out of the wallet and gets deto1. Addresses are bech32, so the prefix and the checksum both differ and the rule never matches. Same root cause as #26, where the fix was sameINDEXAuthor in tela_service.go.

Why this is latent: initializeDefaultRules only ships rating and epoch_support rules, and there is no App method exposed to the frontend that creates a rule, so no author or category rule can exist yet.