pins.d: a read-only pin layer owned by packages, over the writable pin_store #42

plugin-hostd loads one pin_file at start and keeps first-use pins in pin_store. Pins that ship with packages have nowhere to go, and importing them into the writable store at install time would need package scriptlets and leave two sources of truth.

Proposal: two layers.

• Read-only layer owned by packages: a directory, default /usr/share/plugin-hostd/pins.d/. Every *.pins file in it is loaded at start, in name order, in the same line format as pin_set. The pin_file key stays and may be given more than once.
• Writable layer owned by the host: pin_store, unchanged. First-use pins, accepted changes and anything recorded at runtime go here. No package edits it.

Rules:

• A pin from the read-only layer is trusted as is.
• A writable-store entry for the same plugin with a different hash is refused and announced through pin_changed, until pin_accept takes it, as today.
• A malformed or overlong line in a pins.d file is skipped and reported, not fatal (same rules as the store from Pins: take the pin on first use, keep it, announce a change (#25) #30).
• The directory is owned by plugin-hostd; other packages may co-own it with %dir so they can drop a file in.

Why: the pins of a package's own plugins ship in that package, so the binaries and their pins are replaced in one transaction and removed together. See omx-plugins issue "Ship omx-plugins.pins" for the producer side.

Done when: hostd reads the directory, the manual and the generated key list describe it, tests cover layering and the conflict case, and a release carries it (minor).