With the deterministic channel key changes: `channel update --claim_id <claim_id> --replace` updates public_key(format) and publick_key_id of the channel, which breaks the compatibility with old stuff

Nobody has claimed this yet.

Updating channel with `replace:True`, on a SDK which uses deterministic channel keys, "breaks" the channel for old SDK. (public_key format and public_key_id changes, I think)

Steps to repro:
1. Create a channel on a SDK that doesn't have deterministic channel keys.
2. Run `lbrynet channel update --claim_id --replace` on a SDK that has deterministic keys. (Not intentionally updating keys)
3. The channel's signatures are now considered invalid on older SDK. And channel can't be used for signing on older SDK. (Gives `Couldn't find private key for id....`)

Seems that the SDK with deterministic channel keys uses a different format for channel public keys than old one. But new one also handles the old public keys in the new format. So when one runs something like `lbrynet channel update --claim_id --replace` on a newer SDK, the public_key gets replaced with the new format of the key. And signatures aren't considered valid anymore on current/old SDKs.

Replace seems to do this, which on new SDK returns the compressed version of the key https://github.com/lbryio/lbry-sdk/blob/master/lbry/extras/daemon/daemon.py#L2919

Start with lbry/extras/daemon/daemon.py around line 2919 and reproduce the listed channel-update sequence across old and deterministic-key SDKs. Trace how `replace` selects and stores `public_key` and `public_key_id`, then verify that an update without intentional key changes preserves signatures and remains usable by older SDKs.

Written by the indexing model from the issue text.