What is the problem or limitation you are having?

The publish command exists in stub form across all platforms, but publish_app() is not implemented.

Describe the solution you'd like

Add a plugin interface for publication channels using dynamic discovery via entry points, following the existing pattern for platforms and debuggers. (Discussed in #2678.)

Entry point registration

Channels register scoped by platform and format, following the pattern used by briefcase.formats.*:

[project.entry-points."briefcase.publication_channels.web.static"]
pythonanywhere = "briefcase_pythonanywhere:PythonAnywhereChannel"

Base class and command API

• A BasePublicationChannel ABC with a publish_app(app, command, **options) method.
• A Protocol type (PublishCommandAPI) defines the stable API surface exposed to plugins (console, tools, project_path(), distribution_path()), starting minimal and growing as needed.

Changes to PublishCommand

• Dynamic channel discovery via get_publication_channels(platform, format) using importlib.metadata.entry_points(), same as debuggers and platforms.
• Auto-chain: publish triggers package (which triggers build) if needed. All channels go through packaging — the plugin reads from the packaged artifact as the source of truth for what gets deployed.
• Single installed channel is used automatically; multiple channels require --channel.
• briefcase publish -h dynamically lists available channels.
• Remove s3 and ios_appstore placeholders.

Describe alternatives you've considered

Hardcoding publication channels directly in briefcase (e.g., adding PythonAnywhere support as built-in code). This would work but doesn't scale — each new deployment target would require changes to briefcase core and add optional dependencies. (Discussed in #2678.)

Additional context

Out of scope for this ticket (follow-on work):

• Concrete channel implementations (separate packages and/or PRs)
• Default channel config and API token storage in user config (Add ability for user-level configuration options #2279)