feat(core): add applies_to field for layered sticky-rules foundation

[kunickiaj]

Description

Adds explicit applicability scope (user/org/toolchain/project) as a first-class column on memory_items, distinct from scope_id (sharing domain). Foundation for a layered sticky-rules pack band that fights long-context attention dilution by re-emitting standing rules every pack.

• Schema: applies_to TEXT NOT NULL DEFAULT 'project' with a CHECK constraint, applies_to_key TEXT (org/toolchain discriminator), composite index idx_memory_items_applies_to.
• Validation: new applicability module exposes validateApplicability (strict write path — rejects unknown layers, enforces key contract) and normalizeApplicability (lenient read path — unknown layers degrade to project for downgrade safety on inbound peer payloads).
• Replication: recordReplicationOp, buildPayloadFromMemoryRow, parseMemoryPayload, applyReplicationOps (insert + update branches), and the bootstrap snapshot apply path all carry the new fields. The CHECK constraint catches any payload that escapes normalization.
• Tests: 6 db migration tests (column existence, default, composite index + EXPLAIN QUERY PLAN, CHECK rejection, idempotency, raw-insert default), 15 applicability validator tests, 3 replication round-trip tests (carry, future-layer downgrade, missing-field default).

This is the first PR in a stacked feature. Follow-on PRs add viewer-side promotion UI and the layered pack band.

Type of Change

• 🚀 Feature (new functionality)

Testing

• Relevant checks pass locally (pnpm run tsc, pnpm run lint, pnpm run test) — workspace 1951/1951
• Added/updated tests for changes — 24 new tests covering migration, validation, replication round-trip, and downgrade safety
• Manually verified changes work as expected — EXPLAIN QUERY PLAN confirms the composite index is used by the layered-band query; pre-commit reviews caught the SQL CHECK constraint and replication apply-path wiring before merge.

Checklist

• Code follows project style (pnpm run lint passes for touched files)
• Self-review completed
• Documentation updated (if needed) — no doc changes required (purely additive schema foundation; user-visible docs land with the viewer + pack-band PRs)
• No new warnings introduced

[kunickiaj]

• chore(core): log replication-op emit failures in visibility/applicability mutators #1107
• feat(core): split sticky_tokens from pack_tokens so token_budget is honest #1106
• feat(viewer): expose org/toolchain layers in the applicability picker #1105
• feat(core): inject a Sticky Rules band at the top of every memory pack #1104
• feat(viewer): expose applies_to mutation via store + endpoint + feed card #1103
• feat(core): add applies_to field for layered sticky-rules foundation #1102 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[kunickiaj]

Scrapping the layered sticky-rules feature stack. The manual user-pinning premise — "user finds a memory in the feed and clicks a dropdown to broaden its scope" — is friction nobody will reach for. The valuable sticky rules ("use fish shell", "no praise filler") are not memories users would find and pin; they are recurring patterns the observer should infer, and the canonical homes for them already exist (~/.claude/CLAUDE.md for personal prefs, repo AGENTS.md for project rules).

Salvaging the one pre-existing bug surfaced during this work as a focused standalone PR: the silent try/catch swallow around recordReplicationOp in updateMemoryVisibility (the method this PR did not introduce) now logs the failure with the existing [codemem] prefix instead of dropping it on the floor.