Fix test/install, add test-build, verify-results, docs

[jnasbyupgrade]

Summary

• Fix test/install: Replace broken separate-invocation approach with schedule-based single pg_regress invocation — install state now persists into the main test suite
• Add test-build: Pre-test SQL validation via test/build/ with better error messages than CREATE EXTENSION failures
• Add verify-results: Safeguard preventing make results when tests are failing
• Add .asc extension: Recognized as asciidoc alongside .adoc and .asciidoc
• Document all new features in README

Test plan

• Full BATS suite passes (206/206 tests)
• Install persistence test confirms state survives across test phases
• Schedule file auto-generated from test/install/*.sql files
• Auto-detection enables/disables correctly based on file presence
• make clean removes generated schedule file

🤖 Generated with Claude Code

[jnasbyupgrade]

Enhancement request: Override mechanism for install/build file lists

I'm planning to use the test/install support for pg_tle integration in my extensions monorepo. The auto-detection is great for the common case, but I need to control which files run and in what order. Two requests:

1. Documented override for test/install and test-build file lists

TEST_INSTALL_SQL_FILES is auto-populated via wildcard, and the schedule is generated directly from it. There's no clean way to:

• Control ordering: Wildcard gives filesystem order. I need pgtle-setup to run before extensions.
• Conditionally include files: I have a pgtle-setup.sql that should only run when PGTLE_MODE is set (Docker/RDS uses pg_tle; local PGXS doesn't).

Suggested approach: Expose an intermediate variable that the schedule generation uses, documented as the public API for overriding:

# Default: auto-detected from test/install/*.sql (unordered)
# Projects can override for ordering or conditional inclusion.
PGXNTOOL_INSTALL_TESTS ?= $(notdir $(basename $(TEST_INSTALL_SQL_FILES)))

$(PGXNTOOL_INSTALL_SCHEDULE):
	@echo "# Auto-generated - DO NOT EDIT" > $@
	@for f in $(PGXNTOOL_INSTALL_TESTS); do \
		echo "test: ../install/$$f" >> $@; \
	done

Then projects can do:

include pgxntool/base.mk

# Explicit ordering + conditional pg_tle setup
PGXNTOOL_INSTALL_TESTS = extensions
ifdef PGTLE_MODE
PGXNTOOL_INSTALL_TESTS := pgtle-setup $(PGXNTOOL_INSTALL_TESTS)
endif

Same pattern would be useful for test-build (PGXNTOOL_BUILD_TESTS). The auto-detect remains the default — this just gives projects an escape hatch with a stable API.

2. Document new make targets to help with conflicts

Projects that already hand-coded test-build or verify-results (like my archive extension) will hit recipe conflicts on upgrade. The PGXNTOOL_ENABLE_* variables handle this, but only if people know about them.

Suggestions:

• README should have a "New Targets" or "Upgrading" section listing all new target names so upgraders can check for conflicts
• Ideally upgrade.sh could grep the project Makefile for potential conflicts with newly-introduced targets (e.g., grep -w 'test-build\|verify-results' Makefile). This is tricky since you'd be upgrading across potentially many pgxntool versions, but even a best-effort warning would help. Not a blocker for this PR though.