Proposal: clarify the supported Docker workflow before further deployment changes

Context

The repository currently provides a root Dockerfile and a short README example for building and running MarkItDown as a CLI container.

There are several related open discussions and pull requests covering different parts of the Docker deployment story:

• #1433 — publishing through the Docker Hub MCP Registry
• #133 and #202 — exposing MarkItDown through a Web API
• #1184 — publishing a native GHCR image
• #1186 — building and publishing a multi-architecture image
• #1542 — updating the Docker base image
• #1722 — updating published image references
• #181 — multi-stage development and production images

Before opening another Docker-focused pull request, it would be helpful to understand the intended supported workflow.

Questions

1. Is the root Dockerfile intended to remain a locally built CLI image, or is publishing an official image in scope?
2. If images should be published, is GHCR, Docker Hub, or the Docker MCP Registry preferred?
3. Should the CLI image and the markitdown-mcp image be treated as separate deployment targets?
4. Is multi-architecture image support expected for the preferred deployment target?

Proposed next step

Subject to maintainer feedback, I would like to submit a focused PR implementing the preferred Docker deployment workflow.

The PR would not introduce a REST API or Docker Compose setup unless those are explicitly part of the direction maintainers want to support.

I am happy to adjust the scope based on the maintainers' preferred direction.

Start with the root Dockerfile and the README's CLI container example, then review the related issues and pull requests listed in the proposal. Done means maintainers have selected a supported image, registry, deployment target, and architecture scope so a focused implementation can be defined.