Yes — Option C is the right call, and your reasoning is exactly correct: the shared key K ships alongside the template offer in a single merchant→PoS handoff. No separate PoS keypair to register. From PoS's side, K is per-template state, not long-lived identity.
Concretely:
Setup (merchant → PoS, once per template):
K = random 32 bytes // generated by merchant
template_offer = OfferBuilder::deriving_signing_pubkey(...)
merchant ships {template_offer, K} → PoS // application-layer channel; LDK doesn't care which