feat(rtbf): declare which data store keys hold a user's data

[dev-bap]

Started from the observation that rbx config hardcoded InExperienceConfig where the API takes a path parameter.

The Configs API is one transport, not one repository

/creator-configs-public-api/v1/configs/universes/{id}/repositories/{repository} takes the repository as a path parameter, and the vendored spec's Repository enum has eight values:

InExperienceConfig, RecommendationServicesConfig, DataStoresConfig, ExtendedServicesConfig, LeaderboardsConfig, ExperienceUserConfig, JourneysConfig, AntiCheatConfig

crates/rbx-config/src/api/mod.rs:13 had it as const REPOSITORY: &str = "InExperienceConfig". So this is not "one repository is missing", it is a parameter modelled as a constant, with the whole draft/publish/revisions/restore lifecycle already written and repository-agnostic underneath it.

Only two of the eight are documented. All eight have exactly 30 mentions in the spec, which is to say they appear only as enum values: there is no content schema for any of them, because entries is an opaque flat object. Roblox's configs guide has a "Use case | Repository" table with one row, and says repositories "will eventually expand". DataStoresConfig is documented on a different page. The enum's own description explains the rest: "internal repository types are not exposed to allow development and testing before enabling". They are forward declarations, so this PR carries the transport and takes no view on what any repository's entries mean.

That is also why there is no bespoke command per repository: a generic --repository works the day Roblox documents LeaderboardsConfig, with no release of this tool.

Where the client went, and why

rbx_core::api::configs, for the reason send_with_csrf lives there: four crates carried their own copy until they started disagreeing about whether 204 was a success. In this workspace leaf tools depend on rbx-core alone and only aggregators (rbx-check, rbx-import, rbx-doctor) depend on peers, so a second tool reaching the Configs API through rbx-config would have been the first peer-to-peer edge.

rbx config gains --repository, and rbxconfig.toml an optional repository field which is the source of truth for the commands that read it. A flag contradicting the file is refused, naming both:

Error: --repository InExperienceConfig contradicts rbxconfig.toml, which names DataStoresConfig.
Publishing into the wrong repository cannot be undone, so this is not resolved by picking one:
drop the flag, or change the `repository` field.

Every existing invocation is unchanged: no flag and no field means InExperienceConfig, and rbx config init writes the file it always did.

Two bugs in that code

previousDraftHash was threaded through and hardcoded off. overwrite_draft took the parameter; sync_and_publish passed None. Roblox documents it as optimistic concurrency: the request fails when the hash does not match the server's draft. So rbx config sync silently discarded a draft somebody had staged in the Creator Hub, and the draft was gone before they could learn it existed. The draft is now read first, its hash sent, and what was replaced is named on the way past. Not a refusal: pipelines legitimately overwrite, and a hard stop would break them.

The documented limits were not checked locally. 100 keys per repository, 256 characters per key. The 101st key failed as a 400 mid-publish. --dry-run refuses it too now, because a dry run reporting a clean plan for a publish that cannot happen is the wrong answer. Key length counts chars, not bytes, since the guide says "256 characters" and a byte count would refuse 200 accented characters Roblox accepts.

rbx rtbf

DataStoresConfig holds the right-to-be-forgotten deletion templates. rbx config --repository DataStoresConfig can push them today, and that is exactly the problem: its entry model holds an opaque toml::Value, and every mistake in this file is one Roblox accepts and then silently never matches.

• {UserId} is case-sensitive. {userId} is stored happily and deletes nothing. This is the first item on Roblox's own best-practices list.
• A pattern with no token names one fixed key belonging to nobody in particular.
• A whole-store template works on standard stores only.
• An omitted or blank scope means global, which is wrong if your keys are scoped.

None of those produce an error from Roblox. You find out when a legal request goes unfulfilled, and the guidance is to compare patterns against your Luau by hand in the Creator Hub and confirm within 30 days that the data went, which is an admission that nothing verifies it for you.

[[key]]
store = "PlayerInventory"
pattern = "User_{UserId}"
scope = "Scope_{UserId}"

[[store]]
pattern = "Player_{UserId}_Save"

rbx rtbf verify answers the question check cannot: does each template name a data store that exists. Both can agree perfectly on a template naming a store you renamed last year. A store pattern is matched by requiring digits where the token is, so Player_{UserId}_Save does not match Player_Settings_Save: a verify that says yes too easily is worse than none. Ordered stores are reported as unchecked rather than missing, because Cloud_ListDataStores does not list them and a false alarm teaches people to ignore the command.

No lockfile, for the reason rbx config has none: the published config is readable in full, so the remote state is a fetch. Not per env either, because a key naming scheme belongs to a codebase rather than an environment, so --env all publishes the same declaration to each universe.

Wiring, and the enumerations it turned up

Wired the way every declarative tool here is: the binary, rbx check (two rows, so the local rules still run under --offline, and a missing key is Skipped not Error following what tools::config records), the JSON schema, docs/rtbf.md, SUMMARY.md, README, docs/check.md.

Three enumerations that a new tool has to join and that nothing links together:

• crates/rbx/tests/cli_smoke.rs SUBCOMMANDS, which drives the help coverage tests.
• crates/rbx-doctor/src/coverage.rs REQUIREMENTS, the per-config-file scope table. rbxrtbf.toml was missing it, so rbx doctor answered nothing about rtbf coverage. Added, and the "none of ... are here" sentence is now derived from the table instead of restating the file names.
• README claimed every declarative subcommand also writes a lockfile. rbxrtbf.toml has none, so that claim is corrected.

rbx import is the fourth and is not done: adding a Domain::Rtbf touches recorded wiremock fixtures I cannot re-record offline, and whether adopting a universe should adopt its deletion templates is a decision rather than a mechanical addition. docs/import.md says so under "What it cannot import", with the hazard stated: writing rbxrtbf.toml by hand after an import and running sync would clear whatever the universe had. Pull first.

Verification

Workspace suite green. fmt, clippy --all-targets and the rustdoc lint clean. cargo run -p rbx-schema -- --check exits 0 with schemas/rbxrtbf.schema.json committed.

Smoke-tested on the built binary: rtbf --help listing six subcommands, init then show on a fresh file, show on the worked example printing the sample keys Roblox will look for, a miscased {userId} refused with the case-sensitivity message, rbx check reporting both rtbf rows with and without --offline and without a key, --repository DataStoresConfig reaching the right path, an unknown repository listing the eight, the flag-versus-file contradiction refused, and sync --dry-run refusing a 101st key.