Add authorship and maintainer inheritance to the Python client #30

Problem

DBPort currently has no explicit authorship or maintainer model. As soon as multiple maintainers work in one repository or one maintainer publishes on behalf of another, the system cannot answer who owns a model by default and who actually performed a publish.

We want authorship to be designed in the Python client first, with the CLI remaining a thin wrapper around those semantics.

Goal

Introduce a lightweight authorship model with:

• repository-level default maintainer
• optional per-model maintainer override
• automatic resolved actor stamping on publish
• immutable version-level provenance separate from mutable project ownership

Product rules

• Default maintainer is configured once per repository context.
• A model can override that default maintainer.
• If no model maintainer is set, the default maintainer is used.
• If neither is configured, DBPort falls back to a stable anonymous actor.
• Version-level published_by records the actor who executed the publish.
• Changing model ownership later must not rewrite historical published_by values.

Python client design

The Python client should be the source of truth for this feature. Suggested surface:

port.maintainer.default.set(...)
port.maintainer.model.set(...)
port.maintainer.model.clear()
port.maintainer.resolved()
port.publish(version="...")  # stamps resolved actor automatically

The CLI should only call into this behavior.

Lock and metadata expectations

• Store default maintainer once at repo or binding scope.
• Store model maintainer only when it overrides the default.
• Store version-level published_by on every version record.
• Keep ownership metadata mutable, but keep action provenance immutable.

Acceptance criteria

• Python API exposes default maintainer, model override, clear override, and resolved maintainer behavior.
• Publish resolves and stores the acting maintainer automatically.
• Model inheritance order is: model override -> default maintainer -> anonymous actor.
• Historical version provenance is preserved when ownership changes later.
• CLI config commands can be implemented as thin wrappers over the Python behavior.
• Docs concept page exists and stays high level.

Related context

This should align with the warehouse-aware lock and sync work, but it is a separate concern from warehouse binding: warehouse binding answers where state belongs, authorship answers who owns or acted on it.