bug: fbird_kill_attachment() returns true but attachment survives on Firebird 3.0

[satwareAG-ironMike]

Summary

fbird_kill_attachment() reports success but the target attachment survives on Firebird 3.0.

Reproduction

Two connections to the same FB 3.0 database (firebirdsql/firebird:3 container):

1. $c1 obtains its own attachment id via SELECT CURRENT_CONNECTION FROM RDB$DATABASE (= 428)
2. $c2->killAttachment(428) -> return value true
3. ~0.5s later, from $c2: SELECT COUNT(*) FROM MON$ATTACHMENTS WHERE MON$ATTACHMENT_ID = 428 -> 1 (still attached)
4. $c1 continues to work normally afterwards: isConnectionValid() === true, ping() === true, prepare('SELECT ...') succeeds

Evidence

Observed 2026-08-22 while writing a dead-link regression test for the Doctrine driver (satwareAG/doctrine-firebird-driver#162). Probe script available on request.

Check	Result
killAttachment() return	true
Attachment row still in MON$ATTACHMENTS	yes
Victim connection usable after kill	yes

Environment

• Firebird server: firebirdsql/firebird:3 (Linux container)
• Extension: satware php-firebird v13.2.x build (2026-08-22)
• Related family: Bug: fbird_drop_table_force returns 'unknown ISC error 0' #8 (fbird_drop_table_force unknown ISC error)

Expected

Either the attachment is terminated (row gone, victim's next operation fails), or the call reports failure instead of true.

Acceptance criteria

• fbird_kill_attachment() on FB 3.0 either kills reliably or returns false/throws on failure
• Regression .phpt covering the two-connection kill scenario

[satwareAG-ironMike]

Reconciliation vs b05776a (#576): unrelated - still valid. Connection-lifetime rework does not touch fbird_kill_attachment / service-manager detachment. FB3-specific attachment survival after kill; needs an fb_lock_print/MON$-based verification harness (same pattern as #578/#586 dig artifacts) to confirm which detach path the FB3 client ignores.