`vector service install` creates a Manual service with no recovery actions, so Vector neither starts at boot nor restarts after a crash

[pos-ei-don]

A note on scope

This is a usability/robustness gap rather than a crash, but it defeats the purpose of running Vector
as a service: after a documented, successful vector service install, Vector does not come back
after a reboot and does not come back after a crash. Both are what an operator installing a service
is buying.

Current behaviour

src/vector_windows.rs:227 creates the service like this:

let service_info = ServiceInfo {
    name: service_def.name.clone(),
    display_name: service_def.display_name.clone(),
    service_type: SERVICE_TYPE,
    start_type: ServiceStartType::OnDemand,   // <-- Manual
    error_control: ServiceErrorControl::Normal,
    executable_path: service_def.executable_path.clone(),
    launch_arguments: service_def.launch_arguments.clone(),
    dependencies: vec![],
    account_name: None,
    account_password: None,
};

service_manager
    .create_service(&service_info, ServiceAccess::empty())
    .context(ServiceSnafu)?;

Two consequences:

1. ServiceStartType::OnDemand means "Manual". The service is not started by the SCM at boot.
vector service start works, but after the next reboot Vector is simply not running, with nothing in
the log to indicate why — the service was never asked to start.

2. No failure actions are configured. Windows' default for a service with no recovery
configuration is to take no action, so an unexpected exit is terminal until someone notices. There is
no set_failure_actions call anywhere in vector_windows.rs, and create_service is called with
ServiceAccess::empty(), so the returned handle could not configure them afterwards either.

Neither point is mentioned in the docs I could find — vector service appears only in
website/content/en/highlights/2022-07-07-0-23-0-upgrade-guide.md and
website/cue/reference/releases/0.55.0.cue, neither of which covers startup type or recovery.

Reproduce

On any Windows host:

vector service install --config C:\ProgramData\vector\vector.toml
sc qc vector

START_TYPE reads 3 DEMAND_START.

sc qfailure vector

RESET_PERIOD 0, no actions.

Reboot: Vector is not running. Kill vector.exe: nothing restarts it.

Current workaround

Two commands, which every Windows deployment currently has to know about and script itself:

sc config vector start= auto
sc failure vector reset= 86400 actions= restart/5000/restart/10000/restart/30000

Suggested fix

• Use ServiceStartType::AutoStart by default, or expose a --start-type flag on
  vector service install if a behaviour change is unwelcome. Automatic seems the far more
  defensible default for a log shipper — a shipper that silently stops shipping after a reboot is the
  worst of both worlds.
• Request ServiceAccess::CHANGE_CONFIG from create_service and set failure actions
  (windows-service 0.8 exposes Service::set_failure_actions), with a restart/backoff schedule and
  a sensible reset period.
• Either way, document the resulting behaviour on the Windows install page.

This is adjacent to #25810 (reporting SERVICE_STOPPED to the SCM when startup fails): that makes a
failed start visible to the SCM, and configured failure actions are what would then let the SCM
actually act on it.

Context

Found while replacing nxlog with Vector on Windows clients. The MSI itself installs no service, no
Run key, no scheduled task and no PATH entry, so vector service install is the intended path — and
following it still leaves you without boot start or crash recovery.

Happy to open a PR for this if the direction is agreeable; I'd want a maintainer's call on whether
changing the default start type is acceptable or whether it should be opt-in.

Version

vector 0.57.0 (x86_64-pc-windows-msvc); code checked against current main.