Curve448 - Can Ed448 key material be reused for X448?

You do not need to convert the Edwards448 public key to the birationally equivalent Curve448 public key in order to do ECDH. You can just stick to Edwards448. There will be a performance gain if you use Curve448, but depending on your implementation this performance gain might be largely offset by the conversion that the verifier will have to do to derive your Curve448 public key from your Edwards448 public key. You would use the "scalar multiplication" function of your Edwards448 EC library to perform the ECDH operation.

EC private keys are "scalars", which means a positive integer less than the group size of the generator point on that curve. Public keys are points on the curve, and are pairs of "field element" coordinates. A field element is a positive integer less than the prime $p = 2^{448} - 2^{224} - 1$.

If you do decide to convert from Edwards448 to Curve448, then those points will share the exact same scalar private key. Note that due to the way that X448 only uses the Curve448 x-coordinate during the the variable-base-scalar-multiplication key agreement, the mapping will be such that both the Edwards448 points $P$ and $I-P$ will map to the same X448 key agreement Curve448 point (where $I$ is the Edwards448 point at infinity). Luckily for you, you are mapping from Edwards448 to Curve448, which means you do not find yourself with an ambiguity.

The conversion from Edwards448 to Curve448 is simply: $$\texttt{curve448}_{x-coord} = \left(\frac{\texttt{ed448}_{y-coord}}{\texttt{ed448}_{x-coord}}\right)^2$$ Note that the "division" is achieved through multiplication with a modular multiplicative inverse. Your EC library should provide you with this functionality. The operations are done $mod\ p$.

Note that Ed448 will start with a 'raw' 57-byte private key, hash it with SHAKE256, clear the most-significant byte, force the second-most-significant byte's most significant bit to 1, and clear the least-significant byte's two least significant bits. Therefore, it's the hashed-and-altered version of your raw Ed448 private key that you need to use identically with Curve448. Curve448 keys are 56 bytes, and it's safe to slice off the most significant byte of the 57-byte hashed-and-altered Edwards448 key, since that Edwards448 key will always contain zeroes in the most-significant byte. Note that since all field elements are little-endian, the "most-significant byte" is the last byte in the byte array.

It's interesting to observe that the BouncyCastle X448 implementation performs a scalar multiplication with the Curve448 base point by asking the BouncyCastle Ed448 implementation to perform scalar multiplication of the exact same scalar against the Ed448 base point. BouncyCastle then converts the result back to the equivalent Curve448 point using the same formula specified in point 4 above. See the code here.