Firstly, thank you for working on this issue.
I took a closer look at your patch, and I think the problem you're seeing - the second run (probably the second one is the network server run, but the order depends on the jvm) fails with 'connection made to existing database instead' is because the sql script creates its own database using the connect statement with ";create=true". Most tests don't test database creation, and can rely on methods in TestConfiguration such as CleanDatabaseSetup or singleUseDatabaseDecorator...But we cannot do that in this case.
Using TestConfiguration.singleUseDatabaseDecorator was a good attempt, but - as you can see by reading the javadoc description of the method - it's creating databases with a specific naming scheme.
CleanDatabaseSetup assumes it will create the database to be used and the name will be 'wombat'.
I think I ran into these same problems before, and ended up creating a separate teardown method in at least one instance, see org.apache.derbyTesting.functionTests.tests.i18n.LocalizedAttributeScriptTest.java.
Note also that the .sql script for that test has a shutdown of the system to ensure the database directories can be removed; ijConnName.sql will need something similar.
Note finally, that as this test uses some hard-coded urls that only reflect embedded, it would be pointless to run this with networkserver; it'll only connect using the embedded driver but start network server for no reason. Perhaps a similar test (.sql file) can be made to use network server urls and run that through NetworkServerTestSetup, but I'd say that would be an improvement beyond the scope of this JIRA.
Apart from the database creation and cleanup issues, I don't think the current test is testing the same as the original one.
Although it certainly manages to create a database using the same (or similar) URL, the original tests some ij specific properties which were set in the _app.properties file. You've rolled those properties into the url in the connect statement in the .sql file, which is not the same thing...
I think you will need to wrap the test in a SystemPropertyTestSetup of some sort to set up those ij properties (which would unset them automatically afterwards).
Finally, you should run the suite through the getIJConfig() method. This ensures that the test only runs when ij is available in the classpath.