Release 1.0.3 Hotfix Latest

Summary
Hardens the first-run setup of the optional Agentic AI (Flowise) component on both deployment paths, and tightens a few related defaults. No change to how the platform is used: the site is published at the same address, and the administrator account is still created by hand on the Flowise Setup Account page.

Flowise 3.1.2 bootstraps its first organization owner through an unauthenticated POST /api/v1/account/register. Only the first caller to reach that endpoint can ever become the owner — every later attempt is refused with "You can only have one organization" — so that endpoint should not be served to a wider network while the database is still empty. These changes narrow who can reach it, and leave everything else about the deployment unchanged.

Changes
Kubernetes (plugins/agenticai/) — the register path is served from its own source-restricted Ingress (flowise-account-setup) controlled by agenticai_setup_source_ranges, defaulting to admitting nothing from the network (setup happens once over kubectl port-forward). The rule matches with a case-insensitive regex rather than pathType: Exact, because Express routes case-insensitively and non-strictly. The restricted rule is created before the root Ingress so there's no unguarded window. Optional agenticai_lock_registration drops the endpoint from the public whitelist once an owner exists. Sets SECURE_COOKIES/APP_URL, passed with --set-string so Helm doesn't type-infer them. Both knobs live in the plugin vars file — nothing was added to core/inventory/agentic-config.cfg.

Docker Compose (docker/) — Flowise publishes on loopback by default (FLOWISE_BIND_ADDR); deploy.sh detects an existing owner on later runs and sets DENYLIST_URLS automatically; NODE_ENV=development removed (Flowise reads it in exactly two places — stack traces at development, forced Secure cookies at production — so unset avoids both); unused FLOWISE_ADMIN_* generation dropped from the vault script; deploy_agenticai_plugin defaults to off.

Docs — quickstart and docker/README.md cover the first-run steps per path, opt-in browser setup, and 403/401 troubleshooting.

Verification
Exercised against a live single-node cluster and a separate Docker host. On Kubernetes: all 12 register path variants return 403 from a non-loopback source (trailing slash, mixed case, duplicate slashes, query string, /./ and /../, percent-encoded %72egister), while /, ping, version, logout, login, chatflows, forgot-password and sibling paths like …/registerfoo are unaffected; port-forward setup works; annotation semantics confirmed both ways on throwaway Ingresses; and an audit of the running image confirms the register route is the only unauthenticated path that creates an organization. On Docker: Flowise unreachable from another host while 127.0.0.1:3000 works locally, the owner-detection query returns the expected count, and an A/B run with and without NODE_ENV gives identical status codes with only the stack trace disappearing.