Align on Hardware Provider Requirements for FlowFuse Device Agent

### Description
Before engaging hardware partners, we need engineering alignment on:

1. What minimum requirements we place on partner hardware
2. How Device Agent is expected to be deployed
3. What the end-user workflow looks like

Goal: make this simple, repeatable, and low-friction for customers.

---

## Two Integration Scenarios

### Scenario A – Managed Mode (Preferred?)
- Disable/remove vanilla Node-RED
- Device Agent is the only Node-RED runtime
- Full lifecycle (provisioning, updates, config) controlled by FlowFuse

Questions:
- Do we require vanilla Node-RED to be removed?
- Do we enforce ownership of port 1880?
- Do we require systemd service control?

---

### Scenario B – Coexistence Mode
- Leave existing Node-RED intact
- Install Device Agent alongside
- Configure via environment variables
- Customer decides which runtime to use

Questions:
- Are we okay competing with a preinstalled Node-RED?
- How do we prevent port conflicts?
- Do we support side-by-side long term?

---

## Minimum Hardware Requirements (Proposed)

- Linux-based OS (systemd preferred)
- Persistent writable storage
- Outbound HTTPS access to FlowFuse
- Stable clock (NTP)
- Sufficient RAM/CPU for Node-RED workloads

Open questions:
- Do we define minimum RAM/CPU?
- Do we require container runtime, or support native install?
- Do we require secure element / TPM for identity?

---

## End-User Workflow (Target)

From customer perspective:
1. Device boots
2. Device appears in FlowFuse (pre-provisioned or claim code?)
3. User assigns to instance
4. Flows deploy
5. Device updates managed centrally

Questions:
- Are we standardizing on claim-code model?
- Who owns first-boot provisioning?
- Do we require factory pre-provisioning?

---

## Ask

Engineering feedback on:
- Preferred integration model (A vs B)
- Non-negotiable hardware requirements
- Simplest provisioning flow for customers

We need alignment before sending requirements to partners.