ledger: an account may be linked to another book's category (documented, unenforced)

[Yaraslaut]

What happens

LedgerModel::setCategoryImpl (behind SetCategory, and the rule cascade in
execute(StoreTransaction)) and BudgetModel::execute(LinkAccountToCategory)
both join an account to a category by id, with no check that the two are in the
same book:

// examples/ledger/src/models/ledger_model.cpp (setCategoryImpl)
auto accountRows  = mapper.Query<db::AccountRecord>()
                        .Where(FieldNameOf<&db::AccountRecord::id>,  "=", *action.accountId).All();
auto categoryRows = mapper.Query<db::CategoryRecord>()
                        .Where(FieldNameOf<&db::CategoryRecord::id>, "=", *action.categoryId).All();
if (accountRows.empty() || categoryRows.empty()) {
    throw NotFound{"SetCategory: no such account or category"};
}
accountRows.front().category = categoryRows.front();

AccountRecord and CategoryRecord each carry their own ledger, so a book
two account can be given a book one category and the row is written.

Why this is filed as a question, not a defect

Unlike morph#367, this is already documented as accepted, in the corpus
itself — scripts/scenario/scenarios/ledger/two-books-are-isolated.scenario
dispatches exactly this and says so:

The second book's account, linked to the first book's category. The link
itself is accepted -- categories and accounts are joined by id, not by book --
but the report below must still not count it, because the report filters
journals by the budget's own ledger.

and the scenario then asserts the budget report is unaffected (it counts book
one's 40.00 and not book two's 15.00). Neither action carries a ledgerId, so
there is no scope argument to filter on: enforcing this would mean comparing the
two rows' own ledgers, which is a different change from #367's.

So the open question is only whether a cross-book link should be refused
rather than merely ignored downstream — a stored row that no report can ever
act on is still a row that a future report, or a GUI listing categories for an
account, could act on by mistake.

Verification status

Partially reproduced. The LinkAccountToCategory half is exercised on a
real ladder_ledger_server by the scenario quoted above, which passes — i.e.
the cross-book link is accepted and the report ignores it. Measured on branch
worktree-agent-a99217a5bca2f10a4 (base 2a035fe8) via
python3 scripts/scenario/run_scenarios.py --rung ledger --build-dir build/ladder-srv --twice,
both passes green.

Not verified: the SetCategory half (same code path, reached through
LedgerModel rather than BudgetModel) was read, not driven. No consequence
beyond the budget report was investigated — in particular whether any GUI
surface or later report kind reads AccountRecord::category without a ledger
filter is unknown, and that is what would size this.

What would change the verdict

• Close it as intended behaviour if the scenario's stated rule ("joined by
  id, not by book; reports filter by ledger") is confirmed as the design, ideally
  by moving that sentence into the rung's design notes rather than leaving it in
  a scenario comment.
• Turn it into a bug if any consumer of AccountRecord::category is found
  that does not independently filter by ledger.

[Yaraslaut]

Triage: rescope — the question this issue asks is answerable today, and the answer is "no consumer acts on it, for a reason that is not written down anywhere"

The issue names the deciding experiment: is there a consumer of AccountRecord::category that does not independently filter by ledger? I ran it.

There is exactly one consumer in the tree:

$ grep -rn "AccountRecord::category" examples/
examples/ledger/src/models/budget_model.cpp:298

and it is the budget report's step 1, which is indeed not ledger-filtered:

auto categoryAccountRows = mapper.Query<db::AccountRecord>()
                               .Where(FieldNameOf<&db::AccountRecord::category>, "=", categoryId).All();

A cross-book account linked to this category is collected into accountIds. What excludes it is step 3: legs are filtered by WhereIn(account, accountIds) and WhereIn(journal, journalIds), where journalIds came from a query filtered on the budget's own ledger (budget_model.cpp:295-322, and the comment there says the ledger filter is "required for correctness"). The foreign account's legs hang off foreign journals, so the intersection is empty. The scenario's claim holds, and the SetCategory half reaches the identical row through the identical downstream.

So by the issue's own criteria this is "close it as intended behaviour, move the sentence out of the scenario comment". That is the rescope: the issue should be rewritten as a documentation task with a stated invariant, not left as an open enforcement question. Three things belong in that write-up, and only one of them is currently anywhere:

1. The rule — accounts and categories are joined by id, not by book. (Today: a comment in two-books-are-isolated.scenario.)
2. The invariant the rule leans on — a report never widens past its own ledger's journals. This is the whole reason a cross-book link is harmless, and it is stated nowhere as a constraint on future reports; budget_model.cpp's comment gives scalability as a co-equal reason for the same filter, so a future report author could reasonably keep the account fan-out and drop the journal filter.
3. The dependency on morph#367 — and this is the part the issue does not mention. The isolation is a two-hop property: a foreign account's leg is excluded because it sits on a foreign journal. morph#367 reports that StoreTransaction will post legs onto accounts belonging to another book. With that unfixed, a book-one journal can carry a leg on a book-two account; if that account is linked to a book-one category (i.e. exactly this issue's scenario), the budget report does count it. "Accepted but ignored downstream" is therefore conditional on ledger: StoreTransaction posts legs onto accounts belonging to another book #367 being fixed, and the two should be cross-referenced.

One more site for the same shape, not currently in the issue: BudgetModel::execute(const CreateBudget&) (budget_model.cpp:185-205) joins a budget to a ledger and a category, checking that each exists and not that the category belongs to that ledger. That is a third instance of "an id resolved without the scope the action names" alongside SetCategory and LinkAccountToCategory, and it is the one that decides which categoryId the report above runs on. Whichever way this is resolved, that site should be named too.

Not a bug: nothing shipped produces a wrong answer today, and the behaviour is asserted-as-intended by a passing scenario.

What would change this verdict: a consumer of AccountRecord::category that does not re-scope by ledger — a new report kind, or a GUI surface listing an account's categories. Today there is one consumer and it re-scopes.