As a matter of fact, a somewhat similar question was asked this morning on Gitter, so I’ll paste here part of my answer there :).
static client registration is vanilla OIDC (even OAuth 2.0) concept, where the app developer uses an out-of-band mechanism to get a client id/secret pair from a given Identity Provier, that the app can later re-use to be identified by the same Identity Provider. In this case, the identifiers is server-managed, and the developer manually provides client information when registering.
On the other hand, Solid Client identifiers (the spec is walking away from calling them WebID for technical reasons, but they’re very much similar to a WebID for apps) is a Solid-OIDC-specific mechanism, where the client is in control of its identifier, which dereferences to a document where client information may be found by the identity provider. Details are provided in the draft spec: Solid-OIDC
In an open ecosystem such as Solid, where a given user is free to use the Identity Provider of their choice, regular static registration doesn’t scale, which is why the alternative mechanism has been proposed.
So to specify in the context of your question: the client (i.e. the app) registration is different from the Pod provisioning. Your client can either be statically registered, or dynamically registered (which is the default behaviour). In any case, the Identity Provider doesn’t have to be related to the Pod provider in any way, that’s the beauty of open systems.
Does that answer your question ?