Agentforce Enhanced Web Chat: "Agents are not available. Try again later." although Agent Preview works

@ANANTHARAMAIAH VENKATA POCHINCHARLA

The fact that Agent Preview works while Enhanced Web Chat fails is the single most useful clue here. It tells us the agent itself, its topics, and its actions are fine. Agent Preview bypasses the routing layer entirely and talks to the agent directly. Enhanced Web Chat goes through Messaging, Omni-Channel routing, and then to the agent. So the break is somewhere in that routing chain, not in the agent. 

That narrows it a lot, and it also points at your fourth question, which I think is closest to the real answer. 

On Developer Edition and backend provisioning, this is where I'd look first. Messaging for In-App and Web with Enhanced Messaging requires Digital Engagement provisioning, and Developer Edition orgs frequently do not have the full Enhanced Messaging backend provisioned even when every Setup screen lets you configure it successfully. That's the trap: Setup will happily let you build the channel, the deployment, and the routing, and everything will look correct, but the underlying messaging infrastructure that actually delivers the conversation to the agent was never turned on. "Agents are not available" is the generic front-end message when that chain can't complete on the backend. This matches your symptom precisely, including the fact that Salesforce's own Test Enhanced Web Chat fails identically, which rules out your snippet and your site.

On the EinsteinServiceAgent user, this is worth verifying carefully because it's the second most likely cause. The Agentforce Service Agent runs as its own dedicated user, and that user needs to be properly configured to receive work. Specifically, confirm the agent user has the Agentforce Service Agent permission set (or the relevant Agentforce permission set license) actually assigned, and confirm the agent user is enabled for Omni-Channel with a presence configuration that includes the Messaging service channel. A very common failure is that the human Omni-Channel user is set up perfectly (which you've done) while the agent user itself is missing the Omni presence configuration or the permission set license, so routing has nowhere valid to deliver the work. Your checklist covers your own user's availability, but the agent user is a separate identity with its own requirements.

On non-obvious prerequisites, a few to verify:

Confirm Omni-Channel itself is enabled and that a Service Channel record exists specifically for Messaging Session, not just Messaging. The routing has to resolve to a Service Channel tied to the MessagingSession object.

Check that your Messaging Channel is actually associated with the Embedded Service Deployment you're testing from, and that the deployment is using the Enhanced (v2) messaging type rather than a legacy configuration. Mixing a legacy channel with an Enhanced deployment produces exactly this kind of silent routing failure.

Verify the Omni-Flow is actually being invoked. Open your NovaMart Chat Routing flow and check whether it has any recent runs, or add a temporary debug element. If the flow never fires, the failure is upstream of routing entirely, which again points to provisioning. If it fires and then fails at Route Work, the problem is the agent user's ability to receive.

My honest read on your four questions: yes, this is common in Developer Edition specifically; the non-obvious prerequisite is Digital Engagement / Enhanced Messaging backend provisioning; the EinsteinServiceAgent user does need its own permission set license and Omni presence configuration beyond what you'd set for a human user; and yes, there is backend provisioning that Salesforce must complete, and in a Developer Edition org that provisioning often simply isn't there and cannot be self-enabled from Setup.

The fastest path to certainty: check whether your Omni-Flow is executing at all. If it never runs, you have your answer and it's provisioning. If it runs and fails at Route Work, focus on the agent user's permission set license and Omni presence configuration. Either way, if you can test the same configuration in a trial org or a sandbox of a fully provisioned org and it works there, that confirms Developer Edition provisioning as the culprit and saves you from chasing config that was never wrong.

Given the effort you've clearly put into the setup, I'd also just log a case with Salesforce Support and ask directly whether Enhanced Messaging and Digital Engagement are provisioned on your Dev org. That's a question only they can answer definitively, and it takes them minutes to check.