Force unsilence record clients on startInput

We call startRecording unconditionally in startInput, so we must
update the client state to be unsilenced (since we are treating as
such). We subsequently re-update the silence state (with the client
marked as active to dispatch ops) in updateUidStates_l.

This fixes an issue where we call startRecording for a silenced client,
then call it again when it moves to unsilenced when the client is active.
Since startRecording is ref-counted, this leaves the client in the
recording state leading to incorrect appop attributions.

Bug: 281485019
Test: Manual verification of repro cases + verbose log analysis
Change-Id: I31d50457ca8adae577407a28d4d4c0e8582bac5d