Granular access to directories within monorepo

How can they give the contractor access to only the relevant client code?

They don't. Confidentiality issues with a full monorepo are simply too important to be mitigated.
And Git itself has no authorization (or authentication for that matter).
Meaning: no amount of native Git feature alone (submodule or subtree) would be enough on their own.

I usually see an intermediate gate repository, composed of the relevant parts for the contractor to work, with a synchronization process to import/export to work.
And if that contractor is working remotely, then that extract would be hosted on a separate server, itself managed in a DMZ, and replicated to an external server on the internet, accessed through VPN?

Consider using git subtree.

With git subtree you will be able to:

• create a monorepo composed of subtrees, each of which can be linked to separate remote repos.

  Given your example use case, the contractor would be given access to only the remote repo tied to a single subtree of the monorepo.

• have a single aggregate/unified history (the point of a monorepo)

• pull changes from subtree remotes into the monorepo

• push changes made in any subtree of the monorepo to its separate remote

• keep your simple/easy workfows.

  git subtree does not require users of your repository to learn anything new. They can ignore the fact that you are using git subtree to manage dependencies."

For a list of pros/cons check out Atlassian's Git subtree: the alternative to Git submodule. Though I think the example steps in this article are rather limited if not outdated.

For step by step demonstrations with git log details at each step:

• The example and steps in Merging multiple repositories into a monorepo, while preserving history, using git subtree are cleaner and more logical than the Atlassian article.

• git subtrees: a tutorial also includes step by step actions and results for making changes in the monorepo and pushing to the subtree repo, and vice versa, and gives some good tips. It does mention one caveat, and that is rebases that include subtree pulls don't work. Another post explains,

  Do not be tempted to rebase this. Push it as is. If you rebase, git subtree won’t be able to reconcile the commits when you do your next subtree pull.

  If you must do a rebase, the follow up Atlassian article I link below provides a workaround.

• I usually hate watching videos but Introduction to Git Subtrees  one looks worth it and has lots of detail. Also it is far more recent (2019) than all the other articles. It's comforting to see in advance what you'll be dealing with.

If you want an under the covers understanding:

• This excellent SO answer explains the difference between git subtree and the git subtree merge strategy (git merge -s subtree). In essence former uses the latter under the covers. In other words git's notion of porcelain vs plumbing.
• GitHub article about Git subtree merges uses the merge strategy if you prefer that approach.
• A followup to the Atlassian article above gets more "Under the hood of git subtree".
• Mastering Git subtrees is also good and mentions a couple of other details that you may or may not find acceptable, and has the most detailed step-by-step actions and results of all the links I've provided.
• For some history on how git subtree came about, and how it works internally, as well as how subtrees are better than submodules, see Git: submodules vs. subtrees.

monorepo-operator is a tool that may make managing your subtree-based monorepo easier. I haven't used it and cannot vouch for it, but might be worth checking out.