## Bar-widget+service plugins are dead on third-party bars

A plugin with kinds `["bar-widget", "service"]` (bar gear + background
service owning a window/IPC target) works fully under the stock bar but its
bar widget silently no-ops under any third-party bar clone.

### Repro (with twiking/omasettings 1.3.0 + a bar clone)

1. `omarchy plugin add https://github.com/twiking/omasettings.git --enable`
   with a third-party bar (e.g. a clone of `omarchy.bar`) active.
2. Click the plugin's gear in the bar, or run
   `omarchy-shell shell summon io.github.twiking.omasettings` (returns `ok`).
3. Nothing happens. No journal error.
4. `omarchy-shell omasettings show` (direct IPC to the service) opens the
   window fine — so the service is alive; only the widget-to-service path fails.

### Root cause

`pluginBarApiFor` (`plugins/bar/Bar.qml:229-242`): the trusted built-in bar
gets `pluginShellForId(moduleName)` (service-capable facade), while
replacement bars get `pluginShellForBarEntry(key, moduleName)` — explicitly
"a service-less entry facade". That facade (`shell.qml:pluginShellForBarEntry`)
creates a `PluginShellApi` with **no `_serviceLookup`**, so `serviceFor()`
always returns null. Any widget written as

```qml
readonly property var service: bar && bar.shell && typeof bar.shell.serviceFor === "function"
  ? bar.shell.serviceFor(moduleName) : null
```

gets null and every `service.show()`/`toggle()` silently no-ops — including
`shell summon`, which routes through `findPanelWidget` → `item.open()`.

### Proposal

Give the bar-entry facade an own-service-only lookup, reusing the `owns()`
check already defined in `pluginShellForBarEntry`:

```js
_serviceLookup: function(requestedId) {
  return owns(requestedId)
    ? shell.serviceFor(shell.pluginRegistry.resolveEnabledId(target)) : null
},
```

This preserves the stated security property (a bar still can't reach *another*
plugin's live service) while unbreaking the documented widget+service pattern
on third-party bars.

### Related

Same reporter hit from the plugin side, where the other half of this
stripped-manifest behavior bites:

- twiking/omasettings#17 (by Dankestrick) — launcher entry never created:
  independently confirms the host strips `__sourceDir` from third-party
  service manifests (`publicPluginManifest`, `shell.qml:316`), so
  `Service.qml onManifestChanged` returns early. Notably, their bar gear
  *works* — consistent with this issue, since they're on the stock bar.
- twiking/omasettings#18 — same launcher report, plus confirmation that on a
  custom bar clone the gear is dead too (widget→service path), pointing back
  here for the widget half.

Together: stock bar = working gear + missing launcher; custom bar = dead gear
+ missing launcher. Both trace to what the host withholds from third-party
plugins.

### Environment

- Omarchy shell with `PluginShellApi`-scoped facades (service-less entry
  facade + `publicPluginManifest` stripping `__sourceDir`, `shell.qml:316`).
- Two monitors (DP-1 focused + HDMI-A-1); third-party bar (clone of
  omarchy.bar) active; plugin enabled and present in `bar.layout.right`.