Architecture – What are the potential problems with operational circular dependency between microservices

Before you do anything else, you should read this introductory article on HTTP authentication to get started.

Oath2 protocol flow is shown below as described in The OAuth 2.0 Authorization Framework:

 +--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

                 Figure 1: Abstract Protocol Flow

The abstract OAuth 2.0 flow illustrated in Figure 1 describes the
interaction between the four roles and includes the following steps:

(A)  The client requests authorization from the resource owner.

(B)  The client receives an authorization grant, which is a
     credential representing the resource owner's authorization

(C)  The client requests an access token by authenticating with the
     authorization server and presenting the authorization grant.

(D)  The authorization server authenticates the client and validates
     the authorization grant, and if valid, issues an access token.

All the resource services need to be able to validate the token. There are "many different and valid ways" to do OAuth2 but I would recommend using cryptographic signatures on the tokens. Then your resource servers can validate the token without reaching out to anything else. Revocation may be a concern however. I gather that initially the token specification was vendor specific but that there is now a standard around this.

As far as username recovery and password resetting goes, I would not consider that part of the authentication service. I would separate that out into it's own process and set of services that is independent of the authentication service.

I think your problem is this:

React Component depends on Controller (to allow for end-user input).

The controller should inject callbacks into your view. For example if you want to call a controller method on click, you would expose a onClick property on your React component and the controller would set the property to call the method on itself.

The view should not know anything about the controller. It should only have knowledge of the model.

// model
function todo(title) {
    return {
        title: title,
    }
}

// view
function View({
    todos,
    onAddTodo
}) {
    return (
        <button onClick={onAddTodo}>Add todo</button>
        {
            todos.map(todo => (
                <p>{todo.title}</p>
            ))
        }
    )
}

// controller
function controller() {
    const todos = [todo('foo'), todo('bar')]

    const addTodo = todos.push(todo('new'))

    return (<View todos={todos} onAddTodo={addTodo}/>);
}

In this example:

controller -> model
controller -> view
view -> model

There are no circular dependencies. You may want to see my answer on how to use DI with react because components are usually deeply nested in React, and DI helps solve the problem of passing dependencies to deeply nested components.

Edit 1:

Your snippet from Edit 1 is how it should be designed. But you say

If my Model does some initialization before the View subscribes to its update broadcasts, then those initial broadcasts will not make it to the View

The view shouldn't subscribe directly to the model. In React, changes to the model should be pushed through properties by the controller into the view. The view should be a pure visual representation of the model--it shouldn't be involved with subscribing and updating itself.