docs: Web Agent Concurrency Model

[brohitbrose]

Is your request related to a problem? Please describe.

It is clear from the documentation that Web Agents run in parallel, usually over multiple cores/threads. Less clear is the concurrency model itself, other than a vague notion that it is Actor-inspired (yet doesn't quite use a traditional mailbox). Additionally, there seem to be a lot of "escape hatches" from Actor patterns available (e.g. asyncStage())

What information would you expect to see in this new document?

I propose a new article called Web Agent Concurrency Model that discusses all of the following points.

I'm reasonably confident that:

• Web Agents run concurrently, usually over multiple threads
• Web Agents have agent lifecycle callbacks and lane lifecycle callbacks (note that we will not discuss the lifecycles themselves)
• Agent and lane lifecycle callbacks belong to a group foo with the guarantee that within a Web Agent instance, at most one of foo can be executing at any given time

I have a hunch, but please clarify

• Using setTimer() schedules a timer function that belongs to foo
• Using stage().task() creates a task that belongs to foo
• A user should not make sequencing inferences about the order of foo execution. For example, consider an agent with one command lane command and value lane value. command.onCommand invokes value.set(someValue). If command is commanded twice in quick succession, a user cannot predict whether the order of executed callbacks will be command.onCommand, command.onCommand, value.didSet, value.didSet, or command.onCommand, value.didSet, command.onCommand, , value.didSet and thus should not have application logic that depends on a predictable order
• However, lanes do have volatile-like guarantees for reading, so calling value.get() after value.set() always behaves as expected. I'm not at all confident about this one, but I figure that's what all the atomic CAS-like operations in our data structures help guarantee
• asyncStage().task() creates a task that DOES NOT belong to foo, but can safely set lanes due to the aforementioned volatile-like guarantee

I have no idea:

• In bullet point from the previous section with command and value, can we even guarantee that two value.didSet()s will be called? (This may be better suited for a ValueLane specific article, but I'd appreciate clarification here)
• If a Web Agent creates a downlink from its own agentcontext, does that downlink's lifecycle callbacks (e.g. ValueDownlink.didSet()) belong to foo?
• Are asyncStage-related calls the only types that don't belong to foo?
• For asyncStage, what are some good guidelines for setting taskWillBlock=true? I'm thinking network calls or possibly really long running tasks. Is there ever a good justification for not having it to true? The one use case I can maybe think of is paralellizing message deserialization from a listener-type consumer that uses a small number of i/o threads.

Additional context
Add any other context or screenshots about the feature request here.