Clarify df.http() security scope vs SQL extension execution

[Copilot]

Current docs could be read as if pg_durable enforces database-wide outbound HTTP controls. In practice, the allowlist/blocklist and SSRF guarantees apply to the built-in df.http() activity path, not arbitrary SQL-callable extensions/functions executed by workflow SQL nodes.

• Scope clarification in user-facing guidance (USER_GUIDE.md)

  • Reworded HTTP security section to explicitly scope enforcement to df.http().
  • Added explicit boundary statement: df.http() controls do not govern arbitrary SQL functions, UDFs, or third-party Postgres extensions.
  • Added operator responsibility note: extension install policy, function grants, and network egress remain DBA-controlled outside df.http().

• Threat-model precision in security spec (docs/spec-security-model.md)

  • Updated SSRF mitigation wording to state “cannot be bypassed” applies to the df.http() execution path.
  • Tightened residual-risk statement to “Low for df.http()” to avoid implying database-global enforcement.

• Resulting doc contract

  • df.http() controls are strong within pg_durable’s built-in HTTP activity.
  • They are not a substitute for database-wide extension/function privilege governance.

These `df.http()` restrictions cannot be bypassed by any database user, including superusers.
They do not restrict arbitrary SQL functions, user-defined functions, or third-party Postgres
extensions that a workflow role can execute from SQL nodes.