Rename remaining internal Karakeep identifiers to Marka

[absolutepraya]

Context

The Marka public-identity cutover tracked by #27 intentionally keeps internal compatibility identifiers unchanged so the external rename stays focused and low-risk.

After that cutover is complete, perform a separate internal-identity migration from legacy Karakeep naming to Marka naming.

Scope

Audit and, where appropriate, migrate internal identifiers such as:

• KARAKEEP_* environment variables
• @karakeep/* package scopes/names
• Docker Compose project/service/container naming that still exposes karakeep
• Docker network names such as karakeep-renderer
• internal data/config/cache paths and filenames containing karakeep
• scripts, helper names, constants, protocol/export identifiers, telemetry keys, and other machine-facing identifiers
• repository documentation and examples that describe those internal identifiers

Requirements

• Do not bundle this work into chore(branding): plan and execute the Marka public identity cutover #27. chore(branding): plan and execute the Marka public identity cutover #27 should complete the public repository, GHCR, hostname, and public-reference cutover first.
• Inventory each identifier before renaming it and classify whether it is safe to rename, needs a compatibility alias/migration period, or should remain stable permanently.
• Preserve existing installations and persisted data where practical. Add explicit migration logic or backwards-compatible aliases where a hard rename would break state, automation, environment files, imports, or integrations.
• Treat package scopes, persisted paths, environment variables, Docker resources, and protocol/export identifiers as compatibility-sensitive until proven otherwise.
• Update tests and operator/developer documentation alongside each migration.
• Remove legacy aliases only after their compatibility impact is understood and explicitly approved.

Acceptance criteria

• Complete inventory of remaining machine-facing karakeep identifiers
• Each identifier has an explicit rename/retain/compatibility decision
• Approved identifiers are migrated to Marka naming
• Existing persisted state and supported deployment/configuration paths have a documented migration path
• Relevant tests, CI, local-dev tooling, deployment tooling, and docs are updated
• No accidental public-facing Karakeep branding remains because of internal identifiers

Depends on completion of #27.

[absolutepraya]

Closing this as not planned after the Marka identity migration changed the intended compatibility policy.

PR #44 and the current AGENTS.md now explicitly treat KARAKEEP_* variables, @karakeep/* package scopes, Compose service/project names, Docker network names, export/protocol identifiers, persisted paths, and similar machine-facing names as deliberate compatibility identifiers to preserve rather than broad rebranding targets.

A repository-wide internal rename would therefore add migration and compatibility risk without matching the current product direction. If a specific legacy identifier later creates a concrete operational or user-facing problem, it should be tracked as a focused migration issue with its own compatibility plan.