Support Dynamic Workflows for agents other than main.agent.md

> Please provide us with the following information:
> ---------------------------------------------------------------

### This issue is for a: (mark with an `x`)
```
- [ ] bug report -> please search issues before submitting
- [x] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)
```

### Minimal steps to reproduce
> 1. Create an agent file whose name is not `main.agent.md`, such as `report.agent.md`.
> 2. Add `workflows.enabled: true` to its front matter.
> 3. Start the Function App.
> 4. Observe that the setting is ignored and the runtime logs that `workflows.enabled` is only honored on `main.agent.md`.

### Any log messages given by the failure
> `workflows.enabled is only honored on main.agent.md; ignoring workflows for agent `

### Expected/desired behavior
> Any discovered `*.agent.md` should be able to opt into Dynamic Workflows independently. Workflow control tools, the system prompt addendum, and the effective workflow-tool allowlist should be scoped to that agent rather than being restricted to the filename `main.agent.md`.

### OS and Version?
> All supported platforms.

### Versions
> Dynamic Workflows v1.

### Mention any other details that might be useful

> The current implementation marks an agent as main only when its source filename exactly equals `main.agent.md` (`config/loader.py`), and `app.py` only calls `build_workflow_integration` for that agent. This forces applications to rename an otherwise appropriately named agent merely to enable workflows and prevents multiple workflow-enabled agents in one Function App.
>
> Acceptance criteria should include per-agent enable/disable behavior, per-agent `workflows.exclude`, isolation of tool inventories and system addenda, and tests with multiple workflow-enabled agents. Related umbrella proposal: #90.

> ---------------------------------------------------------------
> Thanks! We'll be in touch soon.

Start in config/loader.py, where an agent is marked as main, and app.py, where build_workflow_integration is called. Trace how workflows.enabled and workflows.exclude are handled, then inspect the existing workflow integration tests if present. Done means multiple *.agent.md files can independently enable or disable workflows with isolated tool inventories, system addenda, and effective allowlists.

Written by the indexing model from the issue text.