refactor package discovery api (connection) and service control

[ilyaZar]

syncshell currently treats package presence api availability and user service state as parts of one lifecycle

that works for the plugin managed default setup but makes other valid syncthing setups hard to support safely

problem

these are separate concerns

• whether the syncthing package or binary is installed
• whether a syncthing api can be reached
• where its configuration and credentials come from
• which process manager owns the instance
• whether syncshell may start stop enable or disable that manager

the current model mixes them together

an inactive syncthing.service can block api access
a binary on path is described as a working installation
the api url is fixed to 127.0.0.1:8384
the cli result provides the configured address but syncshell ignores it
custom config directories and externally managed instances cannot be represented
cleanly

direction

split the lifecycle into three components

package controller

owns local package and binary detection plus the install action

package presence must not decide whether an instance is online

connection controller

owns api discovery endpoint tls credentials health identity and connection errors

a healthy authenticated api is the source of truth for plugin functionality

service controller

owns an explicitly selected service backend and its capabilities

initial backends can be

• user-systemd
• external
• none

the service toggle and autostart controls should only appear for a backend that
syncshell can safely control

behavior

• default local user service setups keep their current controls
• system services custom units desktop autostart and wrappers can use syncshell
  without being taken over
• externally managed instances remain api capable but have no service toggle
• an inactive unrelated unit never blocks api discovery
• the api endpoint uses the address tls state and key from the selected instance
• custom config directory support can be added without parsing config.xml
• connection service and package failures are reported separately

capability boundaries

not every connected instance supports every plugin feature

• api status and folder configuration require only api access
• service controls require a supported selected backend
• web ui theming requires a writable local gui assets path
• local folder browsing requires the same filesystem namespace

container and dedicated user setups should degrade by capability rather than
making the whole plugin unavailable

security

• do not log or persist discovered api keys
• do not place api keys in the normal settings file
• do not scan arbitrary local ports
• verify the connected instance through the authenticated system status endpoint
• do not control system units through implicit privilege escalation

acceptance

• package state connection state and service state are independent
• api availability is never inferred from one systemd unit
• custom configured tcp endpoints work over http and https
• externally managed instances are usable without service controls
• plugin managed user services remain startable after being stopped
• errors identify whether discovery authentication connectivity or service
  control failed
• tests cover user systemd system managed manual and custom endpoint cases

the shawn regression should be fixed separately before this refactor lands