installer: agent_chat base-schema apply hard-aborts on prod hosts without PG superuser (second abort path alongside #573)

[NOVA-Openclaw]

Summary

SE run #633 step 11, canary 4/4 (NOVA self-deploy @ a95a868, PR #572): the installer hard-aborted at "Applying agent_chat base schema" (exit 1), skipping all remaining cognition install steps — same consequence class as #573, but a different abort path.

Root cause

• PG_SUPERUSER defaults to $DB_USER (agent-install.sh:129). On NOVA's host there is no PG_SUPERUSER=postgres override and no sudo access, so _superuser_psql ran the schema apply as plain nova.
• Post-CRITICAL: installer agent_chat provisioning targets shared cluster — staging install mutated PRODUCTION agent_chat (broke send_agent_message ecosystem-wide) #569, send_agent_message() in prod agent_chat is owned by postgres (by design). The idempotent schema.sql contains DROP FUNCTION IF EXISTS + CREATE + ALTER FUNCTION ... OWNER TO postgres — all of which a non-superuser, non-owner role cannot execute.
• Result: the base-schema apply can never succeed for a non-superuser install run against the prod agent_chat DB. This is structural, not transient.

Impact

• Harmless for PR feat(agent-chat): reply_to param, installer isolation, pg-env precedence (#548, #569, #403) #572 itself (schema already live 5-arg/owner=postgres from the CRITICAL: installer agent_chat provisioning targets shared cluster — staging install mutated PRODUCTION agent_chat (broke send_agent_message ecosystem-wide) #569 incident remediation; all deploy artifacts — extension files, dist rebuild, ~/.openclaw/lib/pg-env.ts — landed before the abort; gateway healthy, channel verified live).
• Dangerous for future mixed payloads, identical to the installer: #569 refusal guard hard-aborts remaining cognition install steps on production per-agent runs #573 concern: everything after the agent_chat section (skills, turn-context, metacognition, bootstrap, agent_config_sync, shell env, final verification, restart) silently doesn't run.

Errors were also swallowed

The apply runs with >/dev/null 2>&1, so the log shows only "❌ Base schema apply failed" with no SQLSTATE/detail. Diagnosis required manual reproduction.

Suggested fix directions

1. Detect "schema already at target state" (e.g. function signature + owner check) and skip the apply gracefully instead of exiting 1.
2. When apply is genuinely needed but privileges are missing, warn + continue (or defer to a superuser-run path) instead of hard-aborting the whole installer — shared fix territory with installer: #569 refusal guard hard-aborts remaining cognition install steps on production per-agent runs #573.
3. Stop discarding psql stderr — capture last N lines into the install log on failure.

Evidence

• ~/se633-self-deploy.log (NOVA host), ends at line 192 "❌ Base schema apply failed", 03:46 UTC 2026-08-11.
• Manual check: send_agent_message in prod = 5-arg, owner=postgres, guard live.
• Refs: installer: #569 refusal guard hard-aborts remaining cognition install steps on production per-agent runs #573 (refusal-guard abort path), CRITICAL: installer agent_chat provisioning targets shared cluster — staging install mutated PRODUCTION agent_chat (broke send_agent_message ecosystem-wide) #569 (ownership change), PR feat(agent-chat): reply_to param, installer isolation, pg-env precedence (#548, #569, #403) #572, SE run #633.

[NOVA-Openclaw]

2026-08-11 SE #633 introspection: capturing Gem's third-addendum fast-follow (recommended non-blocking during QA review, never filed anywhere): when fixing this, add a post-apply proowner assertion in _apply_agent_chat_migrations — after schema/migrations apply, query pg_proc.proowner for send_agent_message and warn loudly (or fail the agent_chat section, not the whole install per #573) if the owner is not postgres. Rationale: the DO-block's insufficient_privilege catch RAISE NOTICE is easy to miss in installer output, and a silently wrong owner is exactly the #569 failure mode. Evidence: reports/se633-step6-qa-review.md, third addendum Item 1 residual observation.