Research first-class orchestration within Awa's queue-engine scope

## Context

There is a legitimate question about whether Awa should grow some higher-level orchestration primitives on top of jobs, for example explicit `send` / `call` / `delay` style APIs for common multi-step flows.

This needs to be evaluated against the original PRD positioning:

> Postgres-native job execution for Rust and Python. One queue engine, two first-class languages.

And the existing non-goal of becoming a workflow engine:

- no DAG authoring
- no saga orchestration system
- no broad workflow-engine repositioning

## Research Questions

- Is there a narrow orchestration surface that improves developer ergonomics without changing Awa's product shape?
- Which use cases are in-scope for Awa and which should remain out-of-scope?
- How does this relate to existing ideas like job dependencies (#14)?
- Would the right abstraction be child jobs, typed calls, delayed sends, or just better library helpers?
- What operational/debugging surface would be required if we add orchestration semantics?

## Deliverable

A recommendation that clearly answers one of:
- do nothing,
- add a small orchestration helper layer, or
- define a very constrained first-class orchestration API.

Any proposal should explicitly restate the non-goals and explain why it does **not** turn Awa into a workflow engine.