feat(agent-loop): make the parallel tool-call cap a user setting

The section is a strict subset of the plugin config: `agents` is consumed
once when the service starts, so a stored change there could only look like
it had an effect. The cap resolves through a getter over the settings source,
which the scheduler destructures at the start of each tool group, so a
committed change bounds the next group without disturbing the one in flight.
`resolveMaxParallelToolCalls` becomes the section validator, refusing a value
at the write instead of at that group.

The deferred-resume effect-shape assertion now allows the one plugin effect
the optional settings wiring adds at the fiber's own level; a resumed agent
joining it there is still the regression it pins.

packages/core/agent-loop/tests/config-session-id.spec.ts

@@ -344,7 +344,10 @@ describe('config-driven session id', () => {
 
     const resumeEffect = loopFiber.getEffects().find(effect => effect.label === 'agentLoop.resume(main)')
     expect(resumeEffect?.children.map(child => child.label)).toEqual(['ctx.plugin()'])
-    expect(loopFiber.getEffects().filter(effect => effect.label === 'ctx.plugin()')).toEqual([])
+    // Exactly one plugin effect sits at the fiber's own level — the optional
+    // settings wiring, whose `ctx.inject` cordis labels like any other plugin.
+    // A resumed agent joining it there is the regression this pins.
+    expect(loopFiber.getEffects().filter(effect => effect.label === 'ctx.plugin()')).toHaveLength(1)
 
     await loopFiber.dispose()
   })