Draft: docs: add monolith development model

What

Adds docs/dev/monolith-development-model.md, the dev-doc home for the monolith delivery conventions, plus its docs/dev/README.md index row. The monolith-planner skill alignment ships separately in a follow-up MR based on this branch, so each lands under its own Conventional Commit prefix and review scope.

Why

Monolith work previously had no citable home for its delivery conventions; the monolith-planner skill carried them inline, where they serialized frontend work behind backend MRs and drifted from decisions as they evolved. The model doc records the convention once, for both plan authors and step-MR reviewers:

• Workstreams: the GraphQL surface ships ahead of the frontend plan, batched across slices sharing a type (for example ArtifactRegistryRepository); frontend plans carry no backend edges.
• MR breakdown: Vue steps land route-first with no backend Depends on:; they ship the view's query document with AR fields marked @client (the monolith fe_guide's documented ahead-of-backend pattern, which graphql-verify skips) and mock the Apollo layer the directive implies. Fake-data local resolvers travel as a reviewer GDK patch, not merged code. A connect step per view removes the directive (binding the document to the schema) and carries the cache type policies, GraphQL fixtures, and :js feature spec as the only schema-bound MR.

This mirrors how the Virtual Registry UI shipped (UI epic against an API already in place) while staying inside the ADR-014 resolver pattern. The doc lives separately from development-model.md so monolith planning sessions load only monolith-relevant conventions; MR sizing is cited from MR size guidelines rather than restated.

🤖 Generated with Claude Code