A refusal raised by a database guard is shown to anyone, so its words must be written for anyone #2557

A refusal raised by a database trigger now shows its message only if it starts with forge: . Any other trigger message gets a 403 {error:"refused", message:"refused"}, and the original is logged in full. The new and edited tests pass. bun x tsc --noEmit couldn't run here (no bun types in the sandbox), so the type check is unverified.

• Pass-through: the rule lives in a new src/http/refusal.ts, and failure() in src/http/server.ts applies it. The existing refused by the database warning now logs reason=<original> and shown=<what the caller got>.
• Tests:

- test/accounts.test.ts checks that a prefixed trigger message comes back verbatim. - It also checks that an unprefixed message gives an anonymous-style 403 with the generic text, with the original in the log. - test/refusal.test.ts is a small unit test of the rule.

• Existing tests: I changed the two trigger messages in test/accounts.test.ts and test/sentinel.test.ts to carry the prefix, because the old unprefixed text would now be hidden. The tests were wrong under the new rule; the code wasn't.
• Docs:

- The README has a "Writing a database guard" section. - Migrations 62, 70 and 81 each have a header comment saying their messages are shown to any caller.

Not done, and to check before merge:

• The comments are in the file headers, not beside each RAISE. test/schema-migrations.test.ts hashes the numbered migrations' text, so a comment inside the SQL fails it. I tried that first and reverted it.
• I didn't rewrite the messages in migrations 62, 70 and 81 for the same reason, and schema-additive forbids dropping their triggers. Instead those four messages are listed by name in refusal.ts and still pass through.
• Any operator-installed trigger already in production without the prefix will start answering "refused". That includes the new-account holds. The operator needs to re-create those with forge: on the front. The logs will show the original text.

Try it: bun test test/accounts.test.ts test/refusal.test.ts.

Closes #723

A refusal raised by a database trigger now shows its message only if it starts with forge: . Any other trigger message gets a 403 {error:"refused", message:"refused"}, and the original is logged in full. The new and edited tests pass. bun x tsc --noEmit couldn't run here (no bun types in the sandbox), so the type check is unverified.

• Pass-through: the rule lives in a new src/http/refusal.ts, and failure() in src/http/server.ts applies it. The existing refused by the database warning now logs reason=<original> and shown=<what the caller got>.
• Tests:

- test/accounts.test.ts checks that a prefixed trigger message comes back verbatim. - It also checks that an unprefixed message gives an anonymous-style 403 with the generic text, with the original in the log. - test/refusal.test.ts is a small unit test of the rule.

• Existing tests: I changed the two trigger messages in test/accounts.test.ts and test/sentinel.test.ts to carry the prefix, because the old unprefixed text would now be hidden. The tests were wrong under the new rule; the code wasn't.
• Docs:

- The README has a "Writing a database guard" section. - Migrations 62, 70 and 81 each have a header comment saying their messages are shown to any caller.

Not done, and to check before merge:

• The comments are in the file headers, not beside each RAISE. test/schema-migrations.test.ts hashes the numbered migrations' text, so a comment inside the SQL fails it. I tried that first and reverted it.
• I didn't rewrite the messages in migrations 62, 70 and 81 for the same reason, and schema-additive forbids dropping their triggers. Instead those four messages are listed by name in refusal.ts and still pass through.
• Any operator-installed trigger already in production without the prefix will start answering "refused". That includes the new-account holds. The operator needs to re-create those with forge: on the front. The logs will show the original text.

Try it: bun test test/accounts.test.ts test/refusal.test.ts.

A refusal raised by a database trigger now shows its message to the caller only if it starts with forge: . Any other trigger message gets a 403 with the generic text refused, and the original is logged in full.

The type-check failure is fixed. In test/accounts.test.ts the log-spy array typed fields as optional, which exactOptionalPropertyTypes rejects. It is now Record<string, unknown> | undefined. tsc --noEmit is clean and test/accounts.test.ts passes (22 tests). The forge's check will run on this push.

• How it works: the rule is in a new src/http/refusal.ts, applied by failure() in src/http/server.ts. The refused by the database warning now carries both reason=<original> and shown=<what the caller got>.
• Built-in guards: the messages from migrations 62, 70 and 81 predate the prefix and still pass through. The numbered migrations' text is frozen, so they are listed by name in refusal.ts. Each of those migrations has a header comment saying its messages are shown to any caller. The comments sit in the file headers, not beside each RAISE, because a comment inside the SQL changes the frozen hash and fails test/schema-migrations.test.ts.
• Tests: test/accounts.test.ts covers a prefixed message shown verbatim, and an unprefixed one answered generically with the original in the log. test/refusal.test.ts unit-tests the rule. I added the prefix to the trigger messages in test/accounts.test.ts and test/sentinel.test.ts, because the old text would now be hidden.
• Docs: the README has a "Writing a database guard" section.
• Before merge: any operator-installed trigger already in production without the prefix will start answering "refused". That includes the new-account holds. The operator should re-create them with forge: in front. The logs show the original text.

To try it, run bun test test/accounts.test.ts test/refusal.test.ts.

Both of sentinel's blockers are fixed and pushed. A database guard's refusal now shows its text only if it starts with forge: , on the page and in the terminal. tsc --noEmit is clean and the tests I ran pass: refusal, accounts, tui-screens, tui-limbs and schema-migrations.

• Terminal:

- message() in src/tui/screens/common.ts now answers through the same rule, so a trigger refusal in any terminal action shows refused unless it is prefixed. - The two toasts in src/tui/app/app.ts (lines 473 and 879) now go through message() too. - Other errors still show their own message, as before.

• Shared helper:

- refusedByDatabase moved next to shownRefusal in src/http/refusal.ts. - A new refusalText(error) there returns the text to show for a trigger refusal and undefined for any other error. - failure() in src/http/server.ts imports refusedByDatabase and shownRefusal rather than refusalText, because it also logs the original.

• Test: test/refusal.test.ts checks that an unprefixed trigger error gives refused through message(), a prefixed one passes verbatim, and a plain error is untouched. I tested message() directly, not a full tty action.
• Migration comments: the header comments in migrations 62, 70 and 81 are now on their own lines, outside the SQL, so the frozen hash is unchanged.
• README: the "Writing a database guard" section now says the terminal follows the same rule. It also says a hand-installed guard without the prefix answers refused until it is re-created with forge: in front.

The terminal only filters what it shows. It doesn't log the original trigger text, because the toast path has no logger. The operator gets the original only from the HTTP path's refused by the database warning.