Add @Publish with owner-scoped component resolution and monotonic publishing (v0.1.15)

[Volv-G]

(AI-assisted)

Two related changes to component publishing, landed together because the second
depends on the first being owner-scoped and exact.

1. Monotonic component publishing

Publishing a component now compares against the latest published version for the
owner and refuses to move backwards, surfacing the compared digest so a skip or
refusal explains itself. Unreadable rows fail closed rather than being treated as
absent, published state is re-checked immediately before create to narrow the
race window, and only components proven older are deprecated. A --allow-downgrade
escape hatch exists for the intentional case.

2. @Publish and owner-scoped resolution

@Publish records a component's registry name and version as real CallableRef
fields, and the compiler emits that declaration into the resolver sidecar:

orders-loader:
  name: orders-loader
  version: "1.0"
  publisher: me
  local_from_python: {...}
  publish: true

The declaration uses the entry's own generic name/version fields, so
ordinary hydration looks the published component up and uses local_from_python
only when no such component exists yet. A registry error is not a fallback —
resolution fails closed instead of quietly building from local source.

publish is a separate literal true. Publication is never inferred from
name + version + local_from_python, so a hand-written or fallback entry of
that shape is not silently published.

Why publisher: me

A name is not an identity control. Without an owner the lookup is global, and a
component published by someone else under the same name and version is a valid
candidate — so a collision or a squat could be resolved and deployed in place of
the author's own component. The window is real: a marked entry resolves by name
until its first publication.

The compiler cannot write an account id, because compilation is offline and must
stay so, and baking one author's account into an artifact would be wrong anyway.
It writes the symbolic me, which hydration resolves to whoever is authenticated.
If the account cannot be determined, resolution fails closed rather than widening
to a global search.

The symbol is interpreted only alongside publish: true, which the compiler
always writes together. So me is not a reserved account id: a hand-authored
publisher: me is still used verbatim, and still resolves without requiring
authentication.

Exact owner filtering

The API owner parameter is a substring match, so for an exact published_by
request the server result is only a prefilter. The client now post-filters the
returned rows: a superset id (alice matching alice2) and a row with no owner
are both refused, and the client does not assume the server enforced the filter
it was given. Explicit published_by_substring callers keep partial matching.

This also tightens the publisher's owner-scoped version check, which should not
treat another account's components as its own.

Identity parsing is shared by the publisher and the hydrator, so the two cannot
disagree about who the current user is.

Not part of dedup identity

Publication metadata is deliberately excluded from component identity, so two
agreeing declarations remain one component.

Notes

• Version bumped to 0.1.15 across the four sites prior release PRs touch.
  uv lock was not run; the lockfile self-entry is edited in place.
• Compiling performs no network, registry, or publication side effects. The
  decorator is an inert metadata stub.