T-SQL: bracket-quoted identifiers keep their brackets — [dbo].[Customer] becomes the label `dbo].[Customer`, so no lookup by real name matches

[YNFM]

Summary

The SQL extractor splits a bracket-quoted T-SQL identifier on the wrong characters, so
[dbo].[Customer] becomes the node label dbo].[Customer — with the schema's closing bracket and
the name's opening bracket both retained.

Bracket quoting is the default output of SQL Server Management Studio's script generator, so in
practice this affects essentially every T-SQL file that was scripted out of SSMS rather than
hand-written.

Repro

schema.sql, three statements, nothing else in the directory:

CREATE TABLE [dbo].[Alpha] (
    [Id] INT NOT NULL PRIMARY KEY
);
GO

CREATE TABLE [dbo].[Beta] (
    [Id] INT NOT NULL PRIMARY KEY
);
GO

CREATE TABLE [dbo].[Gamma] (
    [Id] INT NOT NULL PRIMARY KEY
);
GO

graphify . --code-only

Actual

labels: ['schema.sql', 'dbo].[Alpha', 'dbo].[Beta', 'dbo].[Gamma']

Expected

labels: ['schema.sql', 'dbo.Alpha', 'dbo.Beta', 'dbo.Gamma']

The identical file with brackets removed produces exactly that, so the extraction path is otherwise
working — it is only the quoting that is mishandled:

CREATE TABLE dbo.Alpha ( Id INT NOT NULL PRIMARY KEY );

labels: ['schema.sql', 'dbo.Alpha', ...]

Why it matters beyond appearance

The mangled string is the node label, which is the handle every lookup uses. graphify explain,
graphify path A B, and the MCP get_node / shortest_path tools all take a label, so a user or
agent asking about dbo.Customer — the name in every query, script and error message they have
ever seen — does not match the node. They get a miss, which reads as "not in the graph" rather than
"spelled differently internally".

On our own corpus this showed up as 9 of 15 god nodes carrying a dbo].[ label. That is the
architectural summary of the codebase, and more than half of it is unsearchable by the name the
objects actually have.

Environment

• graphify 0.9.39, tree_sitter_sql present (confirmed importable)
• Python 3.14.2, Windows 11
• --code-only, so this is the local AST path with no LLM involved

Note

There is a second, more serious T-SQL defect found while building this repro — a bracketed foreign
key dropping the child table and emitting a fabricated EXTRACTED self-loop. Filed separately since
it is a correctness bug rather than a naming one, and the two do not appear to share a trigger:
every case here mangles labels, but only some drop nodes.

[shard-c6]

Fixed in PR #2716. Bracket-quoted identifiers are no longer mangled into strings like dbo].[Customer].