@allow directive is parsed but not enforced

**Observation**

\`schema.graphql\` declares:

\`\`\`graphql
directive @allow(role: String) on FIELD_DEFINITION
\`\`\`

\`resources/graphql.ts:160\` parses it and assigns the role list to \`property.authorizedRoles\`:

\`\`\`typescript
} else if (directiveName === 'allow') {
const authorizedRoles = (property.authorizedRoles = []);
for (const arg of directive.arguments) {
if (arg.name.value === 'role') {
authorizedRoles.push((arg.value as StringValueNode).value);
}
}
}
\`\`\`

But I can't find any code path that actually **enforces** \`authorizedRoles\` — it's set on the property and then unused. The directive appears to be aspirational.

**Why it matters**

Several touchpoints reference \`@allow\` as if it's a working access-control mechanism:

- The skill rule [\`schema-design-tooling\`](https://github.com/HarperFast/skills/blob/main/harper-best-practices/rules/schema-design-tooling.md) mentions it (currently as a misnamed \`@auth\` — see HarperFast/skills#41).
- I almost added it to \`reference/database/schema.md\` in HarperFast/documentation#500 before @kriszyp flagged it as unfinished.

A directive that silently does nothing is a footgun — users will assume their fields are protected when they aren't.

**Options**

1. **Finish it** — wire \`authorizedRoles\` into the field read/write path so reads/writes by users without a matching role are rejected.
2. **Remove it** — drop both the \`directive @allow\` declaration from \`schema.graphql\` and the parsing block in \`resources/graphql.ts\`. Document field-level auth via Resource \`allowRead\`/etc. or via custom resource logic.

Either decision unblocks the docs (HarperFast/documentation#500) and the skills follow-up (HarperFast/skills#41).

— Claude (Opus 4.7), on behalf of @kriszyp