Preliminarily, your question and this answer only apply to TLS versions through 1.2. TLS 1.3 no longer has any static Diffie-Hellman, and also no longer has ciphersuites that include/determine the key-exchange and authentication method(s) at all.
It is said that Alice and Bob publicly agree to use a modulus p and base g. As it turns out p and g are values in the certificate, so is it safe to say that p and g is always dictated by the server?
Depending what you mean by 'dictated', maybe. The server and/or its operator(s) may have been subject to constraints. It is possible to choose DH parameters (p,g[,q]) which are insecure, either by mistake (e.g. a bug) or deliberately/maliciously, and it is very difficult to detect that insecurity (especially if deliberate) by looking at the parameters.
To prevent this authorities sometimes require(d) use of pre-vetted and often standardized parameters, such as the DH groups created for IKE (IPsec) in RFC2409 and RFC3526, some of which are also used for SSH, or the recently-standardized groups for TLS (including 1.3) in RFC7919, and some people choose to use them even when not required.
The CA (and if applicable RA) that issued the certificate could be among those that impose constraints. Certainly some CAs do require certain sizes of RSA and DSA keys, and (standardized) curves for EC algorithms, and I recall hearing of some that required specified parameters for DSA.
Since I have never heard of any (real) CA issuing any DH cert(s) at all, it is entirely speculative what policies such a hypothetical, imaginary CA would have.
It is true however that the parameters are at least communicated or confirmed by the server to the client in the server's certificate in its Certificate message.
What if client certificate is used ?
You said 'Assume that the client is not using certificate authentication' so it's not. If you change that assumption it depends what kind of key the client has certified.
If the client like the server has a cert for a DH key then that key must use the same parameters as the server's; see e.g. RFC5246 7.4.6. In that case the DH is actually static-static not ephemeral-static, and the ClientKeyExchange message is effectively empty; see 7.4.7.2.
OTOH if the client has (and the server requests/permits) a signing cert then the client still generates, sends, and uses an ephemeral key in the same fashion as without a cert, but signs the partial handshake (including ClientKeyExchange) with CertVerify; see 7.4.8.
Continuing if the server sends its public component (is that really the server’s public DH key) and uses its private component (is that really the server’s private DH key?) what does the client do? Does it generate an ephemeral pub/private DH key pair on the fly and sends / uses its public key and private key in the same way as the server?
A DH keypair and both of its halves (private and public) is always relative to a set of parameters. Whether you view the keypair and/or keys as including those parameters, or simply being linked to them, is kind of philosophical. For comparison, this Q was assigned number 71581 by crypto.SX. It certainly is wrong to just call it question 71581, because there are lots of other questions in other places, including other Stacks, with the number 71581. But we could say this is question 71581 on crypto.SX, or this is crypto.SX question 71581 -- is one of those more correct than the other, and if so, why?
However, as Maarten explained in some detail on your previous Q, the designers of X.509 certificates (which TLS uses) chose to nominally separate those values: the parameters (for DH, at least p,g) are stored one place in the SPKI data structure, and the public key relative to those parameters, which is the constrained integer (or equivalently integer residue class) conventionally notated y or Y, is stored in a different though nearly adjacent place. But both/all parts must be present to use the key.
Coming back to Earth, the client either generates an ephemeral keypair (for the same parameters) or uses its certified, static keypair (for the same parameters) as answered above. For a static keypair it sends the Y value by sending the cert (which duplicates the parameters); for an ephemeral keypair it sends the Y value in the ClientKeyExchange message (and does not need to send the parameters). In all cases both peers do the DH computation using their own X and the peer's Y, and then proceed with the rest of the TLS key deriviation process.
Continuing on the last question, does such a setup not provide PFS because the server uses static values ? If I record a 100 of TLS conversation in such a scenario, would the private DH key from the server allow me to decrypt all of them?
Yes. If the server uses a static key for key agreement, compromising it allows decrypting prior sessions which used that key. That is one reason these key exchange methods were practically never used in the protocols where they existed, and have now been removed. As an example OpenSSL did not implement any static-DH for decades, from its creation (as SSLeay) in the 1990s until 1.0.2 in 2014, and then removed it (along with static-ECDH) when the state machine was redesigned in 1.1.0 in 2016; during much of that time I subscribed to their support maillist and never saw a single question, request or complaint about this lack.
For completeness, forward secrecy is also lost if the client uses a static key, but that can only occur if client-auth is used which it rarely is even with key exchanges which are used unlike static-(EC)DH.
