Opening it as draft as I need to add tests for many possible combinations for the enforce type arguments. This is what I only saw immediately to break the infinite recursion reported in the issue.

Codecov Report

❌ Patch coverage is 70.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.75%. Comparing base (5a6e69f) to head (1a29afd).
⚠️ Report is 5 commits behind head on main.

The documentation preview is ready to be viewed at http://preview.awkward-array.org.s3-website.us-east-1.amazonaws.com/PR3764

@pfackeldey I have added 1K lines of tests all taken from https://github.com/scikit-hep/awkward/blob/main/tests/test_2365_enforce_type.py.
I basically took all those tests and adapted them to check equality of typetracer-backed layouts with the only difference from the original tests regarding assertions being the fact that errors being raised at runtime due to the contents of the data, cannot be raised by typetracers as they do not hold any data. enforce_type basically has to assume that you can actually enforce the type in such cases and the error will be raised during evaluation of the graph when actual data are loaded. For example, using dask-awkward with this PR, this is typetracable but the final line errors upon computation

In [28]: array = dak.from_awkward(ak.Array([1, "hi"]), 1)

In [29]: dak.lib.structure.enforce_type(array, "string")
Out[29]: dask.awkward<enforce-type, type='2 * string', npartitions=1>

In [30]: dak.lib.structure.enforce_type(array, "string").compute()

ValueError: UnionArray(s) can only be converted to string if they are equivalent to their projections

This error occurred while calling

    ak.enforce_type(
        <Array [1, 'hi'] type='2 * union[int64, string]'>
        type = 'string'
        behavior = None
        attrs = None
    )

However, if you slice out the number and keep the string only, it is computable even

In [31]: dak.lib.structure.enforce_type(array[1:], "string").compute()
Out[31]: <Array ['hi'] type='1 * string'>

So during tracing you need to assume that your type enforcement actually works until you look at the data.

In general, a few minor changes were needed. Inspired from the fact that length_zero/one_array uses ak.from_buffers, I also added an actual error message in from_buffers when typetracer backend is requested because it internally has no handling of typetracers and actually never expects the buffers to be typetracers.
to_buffers guards this here:

This should be ready for review from my side.

To support this PR more, I have exposed it to the public API of dask-awkward in this commit in my fork and have added tests for it: dask-contrib/dask-awkward@43fa7ef. They all pass with awkward from this PR branch so I feel pretty confident that this is good to go.