docs: GitFlow branch discipline + OpenSpec install scope

[costezki]

What

Two documentation/skill changes from a session clarifying OpenSpec setup and tightening branch conventions.

1. OpenSpec install scope (docs)

• README.md, docs/environment-setup.md, skills/project-setup/references/spine-projection.md
• Fix the bare openspec init instruction → openspec init --tools claude --profile core (the part that actually registers the /opsx:* commands).
• Document the previously-missing facts: /opsx commands are per-repo + schema-agnostic (with a one-line user-level copy to make them global), and the Meaningfy schema cannot be global — OpenSpec resolves schemas project-local only, so each repo carries its pinned fork via project-setup.

2. GitFlow branch-naming discipline (docs + skill + validator)

• SSOT skills/meaningfy-git-workflow/SKILL.md: replace the old <type>/<ticket-id>/<short-label> (with feat/ example) with the GitFlow model — permanent develop + master (preferred; main alias), temporary feature//release//hotfix/, lowercase+hyphens, --no-ff, off/into table. Banned: commit-type prefixes (feat/, fix/, chore/, rel/).
• Align the duplicate in docs/engineering-standards/git-and-collaboration.md (points to the skill).
• Update tools/repo_lint/lint.py G-DUP anchor to match the new wording.
• release/hotfix lifecycle already lives in meaningfy-release — unchanged.

Validation

make validate passes (the only failures are pre-existing broken links in the untracked voice-extension-and-enhancement change, unrelated to this PR). The branch-pattern assist correctly flags the SSOT + its one known duplicate.

Note

Dogfoods the new discipline: branch is feature/…. Repo currently has only main (no develop); introducing develop is a separate infra decision, out of scope here.