384-bit ChaCha20 / Salsa20
Yes, you have control over $32$-byte key + $8$-byte nonce + $8$-byte counter totalling to a $384$-bit key and this is perfectly safe.

Your only responsibility for this function is to ensure that the $(\text{Key}, \text{Nonce})$ tuple never repeats. The PRG will increment and wrap the counter so this may start randomized. You can still increment the nonce. You could (but probably shouldn't) increment the key.

Alternatively you can use the much more standard IETF variant of chacha20 with a 96-bit nonce and $32$-bit counter or the Xchacha20 variant with $192$-bit randomized nonces and no exposed counter.

Edit: How are we certain that chacha20 is not capped to 256-bit security?

The constants, key, nonce and counter are all treated equally such that a $1$-$2$ bits changing in the counter is safe. The constants exist to weigh the control of the function away from the adversary. The adversary can control the $8$-byte nonce and $8$-byte counter, not the $32$-byte key nor $16$-byte constant. $16 / 64 = 1 / 4$. If the adversary could control the constants then they have $1 / 2$ of the input. A full $384$-bit key gives the adversary only the public constants worth of knowledge (and they know the counter increments). A $512$-bit key means the adversary knows no inputs.