docs: update key assignment doc (#1596)

* update key assingment doc

* improve clarity

* update broken link

docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md

@@ -138,7 +138,7 @@ either using its infraction height or its unsigned timestamp. Note that changes
 The underlying reason is that a malicious validator could take advantage of getting tombstoned 
 to avoid being slashed on the provider ([see comment](https://github.com/cosmos/interchain-security/pull/1232#issuecomment-1693127641)). 
 
-- Currently, the endpoint can only handle _equivocation_ light client attacks. This is because the _lunatic_ attacks require the endpoint to possess the ability to dissociate which header is conflicted or trusted upon receiving a misbehavior message. Without this information, it's not possible to extract the Byzantine validators from the conflicting headers (see [comment](https://github.com/cosmos/interchain-security/pull/826#discussion_r1268668684)). In addition, "amnesia" attacks are ignored, similar to CometBFT (see [ADR-056](https://github.com/cometbft/cometbft/blob/main/docs/architecture/tendermint-core/adr-056-light-client-amnesia-attacks.md#decision)).
+- Currently, the endpoint can only handle _equivocation_ light client attacks. This is because the _lunatic_ attacks require the endpoint to possess the ability to dissociate which header is conflicted or trusted upon receiving a misbehavior message. Without this information, it's not possible to extract the Byzantine validators from the conflicting headers (see [comment](https://github.com/cosmos/interchain-security/pull/826#discussion_r1268668684)). In addition, "amnesia" attacks are ignored, similar to CometBFT (see [ADR-056](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-047-handling-evidence-from-light-client.md#negative)).
 
 
 ## Consequences

docs/docs/features/key-assignment.md

@@ -17,7 +17,7 @@ Key assignment is handled only by the provider chain - the consumer chains are n
 
 ## Rules
 
-- a key can be assigned before the consumer addition proposal passes on the provider
+- a key can be assigned as soon as the consumer addition proposal is submitted to the provider
 - validator A cannot assign consumer key K to consumer chain X if there is already a validator B (B!=A) using K on the provider
 - validator A cannot assign consumer key K to consumer chain X if there is already a validator B using K on X
 - a new validator on the provider cannot use a consensus key K if K is already used by any validator on any consumer chain
@@ -80,3 +80,13 @@ To change your key, simply repeat all of the steps listed above. Take note that
 ## Removing a key
 
 To remove a key, simply switch it back to the consensus key you have assigned on the provider chain by following steps in the `Adding a key` section and using your provider consensus key.
+
+## Querying proposed consumer chains
+
+To query the consumer addition proposals that are in the voting period, you can use the following command on the provider:
+
+```bash
+gaiad query provider list-proposed-consumer-chains
+```
+
+This query is valuable for staying informed about when keys can be assigned to newly proposed consumer chains.