feat: handle charm and model type mismatch at deploy

[sinanawad]

Deploying a Kubernetes (sidecar) charm to a machine model, or a machine charm
to a Kubernetes model, is not something Juju guards against. Unless the charm
declares assumes: k8s-api, both directions deploy cleanly and then break
silently: the unit starts but the workload never runs. When the deploy does
fail, it fails on an incidental check — typically block storage "..." is not supported for container charms — which never mentions the actual problem.

At deploy time the charm is resolved but not yet persisted, so state-backed
checks are unusable on both the client and the apiserver. Charm metadata is
the only available signal, and it has no positive "machine charm" marker; what
it does have is containers:

• Meta.IsSidecar and Meta.ModelMismatch classify the charm and build the
  rejection or warning. IsSidecar matches the row-counting semantics of the
  model's SupportsContainers check, so an empty containers: {} block is
  not a sidecar charm, and subordinates — machine charms with no containers
  by nature — are never flagged.
• The DeployFromRepository result gains an additive Warnings field:
  charmhub deploys resolve server side, and the result previously carried
  nothing short of an error back to the user. Warnings are also logged on the
  controller for API clients that do not render results. The major change
  is in eaa13ac.
• The CLI prints the warning: directly for local charm deploys, and from the
  returned Warnings — ahead of any errors — for charmhub deploys.

Before this change a mismatched deploy produced silence or a misleading
error. After it, both paths print, for example:

WARNING "juju-norma" declares no containers but "mymodel" is a Kubernetes model; it has no workload to run there

Per review, the two directions are treated differently. A Kubernetes charm
on a machine model is unambiguous — the declared containers can never run —
so it is now rejected with a not-supported error (--force downgrades the
rejection to a warning, mirroring the existing assumes behaviour). The
machine-charm-on-Kubernetes direction is inferential (charm metadata has no
positive machine-charm marker), so it remains an advisory warning.

APIBase.DeployFromRepository previously set a result's Info only on
success, which would have dropped the warnings for rejected deploys; it is
now set unconditionally.

Bundle deploys are not instrumented — a mismatched charm inside a bundle
does not warn. The bundle seam is deliberate follow-up scope.

Checklist

• Code style: imports ordered, good names, simple structure, etc
• Comments saying why design decisions were made
• Go unit tests, with comments saying what you're testing
• Integration tests, with comments saying what you're testing (advisory output only; unit tests cover all three layers, manual QA below)
• doc.go added or updated in changed packages (no new packages)

QA steps

Machine charm on a Kubernetes model (charmhub deploy):

$ juju add-model k8stest
$ juju deploy juju-norma -m k8stest
WARNING "juju-norma" declares no containers but "k8stest" is a Kubernetes model; it has no workload to run there
ERROR block storage "blk" is not supported for container charms
ERROR failed to deploy charm "juju-norma"

Kubernetes charm on a machine model (local charm deploy):

$ juju deploy ./juju-norma-k8s_*.charm -m lxdtest
ERROR "juju-norma-k8s" is a Kubernetes charm (it declares containers) but "lxdtest" is a machine model; its workload will not run
$ juju deploy ./juju-norma-k8s_*.charm -m lxdtest --force   # proceeds with a warning

Correct placements emit no warning:

$ juju deploy juju-norma -m lxdtest
$ juju deploy juju-norma-k8s -m k8stest

The controller log carries the same warning for non-CLI clients:

$ juju debug-log -m controller --include-module juju.apiserver.deployfromrepo

Facade change (additive Warnings result field), so model migration was
verified:

$ juju bootstrap lxd src36            # 3.6.24
$ juju add-model moveme1 && juju deploy juju-qa-test
$ juju bootstrap lxd dst40            # this branch, --build-agent
$ juju migrate src36:moveme1 dst40 && juju add-unit juju-qa-test
$ juju debug-log -m dst40:controller && juju debug-log -m dst40:moveme1

The model migrated, the added unit came up active, and the only ERROR-level
log lines are the standard migration-cutover watcher shutdowns and the
fresh machine's "container types not yet available" transient; nothing
references the new field or the application facade.

The 4.0 to 4.0 leg cannot currently be exercised: it is broken on the 4.0
branch itself, independent of this change. The source side of the
password-to-macaroon exchange landed on 4.0 in #22675 and requires
MigrationTarget v8 on the target (internal/migration/auth.go:42), but the
target-side v8 facade landed on main only (#22655, #22674) and has not been
backported, so any password-authenticated 4.0 to 4.0 migration fails at
precheck with "target controller is too old...". This PR touches no
migration, auth or facade-registration files; the leg will be re-run once
v8 reaches 4.0.

Documentation changes

None — advisory warning only; the Warnings result field is additive and no
CLI flags or command shapes change.

Links

Jira card: JUJU-10101

[manadart]

Just some minor ordering/semantic changes.

[SimonRichardson]

We won't need to bump the facade as this is optional, though older facade versions (19 for example) will emit the warnings, though it should be harmless.