[Bugs5382]

What and why

After #286 a node stored nothing for an ACME or EST block that was switched off: an enabled: false block came back from GetConfig empty. The Fleet Manager switches a protocol by reading the config, flipping enabled and applying it back, so switching a protocol on from the Fleet Manager was always refused for a missing base_url and profile.

A switched-off block now keeps its settings:

• FromProto stores the fields of an enabled=false block in PKI.DisabledACME / PKI.DisabledEST, and ToProto sends them back with enabled=false. Flipping enabled alone on the read-back switches the protocol back on.
• The settings sit apart from PKI.ACME / PKI.EST, which stay the only fields the boot path, status and validation read. A switched-off block can't start a listener, and changing only its settings is not a reboot.
• Secrets stay write-only. GetConfig blanks them in a switched-off block, and a blank secret keeps the stored value whether the stored block is on or off. A blank secret for an unknown identifier is still refused.
• An empty enabled=false block still drops the settings (what cryptosctl config apply sends when the block is removed), and an absent block keeps what the node has, on or off.
• In the stored YAML and in config get output, a switched-off block is the acme or est block with enabled: false. A block without the flag is on, as stored configs written before it are. An older image's strict parser refuses the flag instead of reading the block as on.
• A Root still refuses a protocol switched on, and accepts a switched-off block, which it never serves.
• cryptosctl config get --help, and the reboot warnings in docs/acme.md and docs/est.md, said every protocol change waits for a reboot. They now say that switching a protocol on or off, or changing the settings of one that is on, takes effect at the next reboot, and that changing only the settings of a block with enabled: false needs no reboot. TestDisabledSettingsChangeIsLive already covers that NeedsReboot case.

No API change: the fields already exist.

Closes #300

Docs: docs/acme.md and docs/est.md in this PR, and the companion CryptOS-PKI/docs#58 for the machine config reference, the config apply guide and the Fleet Manager switch steps. Merge the two together.

Verification

• Lint clean
• Tests pass
• Build succeeds
• Documentation updated (if behavior or API changed)

How this was verified

• The tests came first and failed on main for the right reason (the switched-off block came back empty), then pass with the change:
  • internal/config/protocols_disabled_test.go: the disabled block round-trips through the proto and through YAML; switch-on from the read-back is accepted, validates, equals the original block (secrets included) and needs a reboot; secrets stay blank in GetConfig and are kept on the node; a blank secret for an unknown key_id is refused; an empty off block drops settings; an absent block keeps them; enabled: true / false / missing / non-boolean in YAML; a settings-only change to an off block is live; a Root accepts an off block and refuses switching ACME or EST on.
  • internal/node/protocols_disabled_test.go: through ConfigStore.Apply and Current, ACME switched off from the read-back keeps its settings with the secret blank in GetConfig, and switching back on from the read-back stores the full block with its secret, answering requires_reboot both ways; EST settings stored while off switch on from the read-back; status reports an off block as not configured.
• The existing feat(config): switch ACME and EST on and off through machine config #286 tests pass unchanged.
• task ci (fmt, golangci-lint, vet, go test, build) passes on the branch rebased onto current main, and task license reports no change.

[Bugs5382]

Merging for the v0.1.0 test run: CI green and mergeable at merge time.