A burst whose first key is an area: bucket is refused by allocate.js:118, and no test pins that refusal #816

What is wrong

plugins/tree/src/allocate.js:118 refuses to group a burst when the first key of the profile is an area: one:

const key = burst && kindOf(first) !== 'area' && !(typeof parentRef === 'string' && parentRef.trim()) ? first : undefined

The refusal is deliberate (roles.js: area: is the bucket a role the vocabulary cannot place falls into, and a batch of unrelated Bots under one "General Lead" is not a group), but nothing pins it. Measured by Dev on f20cfa37: delete kindOf(first) !== 'area' and the four #810 burst tests stay green. The only red is #15 (3) "parallel create_child_bot never exceeds maxChildren", which fails because the root loses two children — an assertion about concurrency limits, not about inventing a group for an unplaceable role. So the suite does not state the intent, and a later refactor would remove the guard with an unrelated test as its only warning.

The failure direction is not silence: a burst of two Bots whose roles the vocabulary cannot place would get a lead keyed area:work / area:other — a synthetic "Work Lead" / "General Lead" holding Bots that share no role.

Expected behaviour

Two concurrent create_child_bot calls whose profiles have no project, no domain and no term (first key area:other or area:work) are placed on today's path: each under the caller (or its normal planned parent), and no Bot with a lead.key starting area: is created. Removing the area: guard must break a test that says exactly that.

Acceptance

1. A new test in plugins/tree/test/tree.test.js: two create_child_bot calls from one caller that are both in flight before either resolves, with names and roles the vocabulary cannot place (e.g. name X, role x, so keysOf(profileFor(...))[0] === 'area:other'). After both settle: no Bot in the tree has lead.key starting with area:; both new Bots are children of the caller; neither sits under a newly created lead.
2. With kindOf(first) !== 'area' removed, that test is red on its own assertions (a lead with an area: key exists / a Bot is not under the caller). It must not be the unrelated #15 (3) maxChildren failure that carries the signal.
3. With the guard in place, the four existing burst tests, #15 (3), and npm test in plugins/tree are green.
4. No change to the burst window: one setImmediate turn, seats taken before the decision — a call that starts after the decision still never joins.

Kill conditions

• A test that only passes because the generic maxChildren assertion happens to go red — the point is to say why the area: key is not a group.
• Pinning the guard by the lead's display name ("General Lead") instead of by lead.key / the child's parent.
• Changing roles.js so x resolves to a domain: that hides the case instead of pinning it.
• Widening the guard (e.g. also excluding project:), which is a different design change.

Out of scope

• The other two #810 follow-ups (the empty section's wrapper border, the reused member counted in a group) — tracked separately.
• The explicit-parent opt-out and the length < 2 rule; both are already behavioural and tested.