Provider-side `LmControlService` reference config has no `allowedConsumer` lockdown

[hskang-amelia]

What

The reference mw::com config that #489 ships for the daemon-side
LmControlService instance (LaunchManager/StateManager/Instance in
test_lmcontrol_mw_com_config.json) has asil-level: "QM" and no
allowedConsumer entry, while the client/consumer-side instance
(StateManager/LaunchManager/Instance) is already locked down with
asil-level: "B" + allowedProvider.

Since #489 removed the old FD-inheritance-based ControlClient
capability model in favor of mw::com service discovery, and
LmControlService itself carries no caller identity/authorization,
the only thing preventing an arbitrary local process from calling
ActivateRunTarget is this deployment config. As shipped, the control
channel is effectively world-writable.

Acceptance Criteria (DoD)

• The reference LaunchManager/StateManager/Instance config sets an
  ASIL level and allowedConsumer restricted to the expected State
  Manager process, symmetric with the existing consumer-side lockdown.
• Docs/examples mention this is required for any real deployment.

How

We verified this works end-to-end against a real daemon build of #489
in a separate repo, using:

{
  "instanceSpecifier": "LaunchManager/StateManager/Instance",
  "serviceTypeName": "/score/mw/lifecycle/LmControlService",
  "instances": [{
    "instanceId": 1,
    "asil-level": "B",
    "permission-checks": "file-permissions-on-empty",
    "allowedProvider": { "B": [0] },
    "allowedConsumer": { "B": [1000] }
  }]
}

uids are whatever the daemon/State Manager processes actually run as;
permission-checks doesn't need to be the literal "strict" as long
as allowedProvider/allowedConsumer are non-empty — communication's
skeleton_memory_manager.cpp routes to UserPermissions{...} rather
than WorldWritable whenever the permission list isn't empty,
regardless of strict_permissions_. Confirmed with a Docker
integration test doing 2 real ActivateRunTarget round trips against
the daemon.

Related: #510 proposes an mw::com "Addon" config mechanism for the
client side, but its example config explicitly notes it has no uid
check either — this gap should be closed regardless of which config
loading path (regular mw::com config vs Addon config) is used.

[hskang-amelia]

Related to #509