Bump to 0.0.11 and fix omni/sigma version drift

[smogili2]

Release 0.0.11

omni and sigma were merged into main after the v0.0.10 tag was cut
and published to PyPI, but the version in pyproject.toml was never
bumped. No published release actually contains these subcommands, so the
agents-schema-omni and agents-schema-sigma actions fail with an
argparse "invalid choice" error regardless of which version (0.0.9 or
0.0.10) they're pinned to — changing the pin alone can't fix it.

What changed

• src/agents_schema/cli.py — omni was missing from the module import,
  causing a NameError before the CLI even reached argparse dispatch.
• tests/test_connector_root.py — the same missing omni import let this
  slip through the test suite undetected, which is how 0.0.10 shipped
  broken in the first place.
• pyproject.toml / uv.lock — version bump 0.0.10 → 0.0.11.
• .github/actions/*/action.yml, .github/workflows/agents-schema-*.yml,
  examples/workflows/*.yml, README.md, RELEASING.md,
  dbt-setup.md, looker-setup.md, omni-setup.md, osi-setup.md,
  sigma-setup.md — repointed every agents-schema==0.0.9/0.0.10 and
  @v0.0.9/@v0.0.10 reference to 0.0.11.

Notes

• uv run python -m unittest discover -s tests — 130 passing.
• uv build && uvx twine check dist/* — both the 0.0.11 wheel and
  sdist pass.
• agents-schema omni --help / agents-schema sigma --help verified
  locally against the fixed CLI.
• This PR does not tag or publish the release. Merge, then follow
  RELEASING.md (tag v0.0.11, push tags, create the GitHub Release) to
  trigger publish-pypi.yml — until that lands, these pins still resolve
  to nothing on PyPI.

Scope

Deliberately limited to this commit only. A follow-up change that makes
each action resolve its agents-schema PyPI version dynamically (instead
of a hardcoded pin) is on main locally but not included in this PR.

[mattsenicksigma]

Sigma related items look good to me!

[fivetran-lukealexander]

Approving. The version bump is consistent everywhere, and the omni import fix resolves a real NameError on agents-schema omni.

One non-blocking note: uv.lock's revision field went from 3 to 2, so this was regenerated with an older uv than the one that produced main's lock. It's functionally fine (uv lock --check passes), but whoever touches this next on a newer uv will flip it back and cause lockfile churn. Might be worth re-running uv lock with a current uv version, either here or in a follow-up.