Nit, but might increase readability by having local use

use outbound_keys_for_user_request::Identifier;
let (user_ident, auth_type) = match message.identifier {
  None => {
    return Err(tonic::Status::invalid_argument("no identifier provided"))
  }
  Some(Identifier::Username(username)) => (username, AuthType::Password),
  Some(Identifier::WalletAddress(address)) => (address, AuthType::Wallet),
};

Valid point. Two tasks will be spawned and thus two RefreshKeyRequest messages will be sent through Tunnelbroker to the device.
So this is about how the device handles refreshing one-time keys.

Olm Account keeps one time keys in a List collection implemented here: https://github.com/CommE2E/olm/blob/6d0eaa993257225faf62768c898fe090fcc2dd2d/include/olm/list.hh. This list is parameterized with its maximal capacity. When new element is inserted into this list and the number of elements stored is already equal to maximal capacity then the oldest element (in FIFO manner) is discarded.

Olm Account uses MAX_ONE_TIME_KEYS constant as maximal capacity: https://github.com/CommE2E/olm/blob/main/include/olm/account.hh#L50, which appears to be equal to 100 https://github.com/CommE2E/olm/blob/6d0eaa993257225faf62768c898fe090fcc2dd2d/include/olm/account.hh#L45. Generating new one time keys simple inserts new elements to the list https://github.com/CommE2E/olm/blob/6d0eaa993257225faf62768c898fe090fcc2dd2d/src/account.cpp#L292. That said successive calls to generate_one_time_keys will discard oldest one time keys if there are already 100 one time keys.