fix(rs_lib): restore stripped deploy.include for workspace-member paths

[crowlbot]

Fixes #90.

Root cause

`deno_config` 0.97's `WorkspaceDirectory::to_deploy_config` calls `exclude_includes_with_member_for_base_for_root`, which strips any user-supplied `deploy.include` entry whose base path falls inside a workspace member directory. That strip is correct when the member has its own competing `deploy` block, but it's over-eager for the common case where the member has no deploy block: the user explicitly listed those paths, and the strip leaves the file collector with an empty include set and zero uploaded files. From the bug report, with this config:

```jsonc
{
"workspace": ["./packages/backend"],
"deploy": {
"org": "myorg",
"app": "myapp",
"include": ["./packages/backend/**"]
}
}
```

the resolver logs:

```
[rs_lib] deploy config: include=Some(PathOrPatternSet([])), exclude=PathOrPatternSet([])
[rs_lib] collect_files(...) -> 0 file(s): []
```

Fix

After calling `workspace_dir.to_deploy_config(pattern)`, re-read the raw `deploy.include` from whichever deno.json owns the `deploy` block (member preferred, root fallback) and re-append any entries that the upstream strip removed. Patterns are compared by their resolved `base_path()` so we don't duplicate entries that genuinely survived the strip.

If/when `deno_config` upstream learns to only strip when the member has its own deploy block, this patch can be dropped.

Test plan

• `cargo test` in `rs_lib/` — 3 passing (the existing workspace-root regression + two new ones below).
  • `workspace_root_deploy_include_targeting_member_glob` — the glob case from the report; asserts both `main.ts` and `extra.txt` appear.
  • `workspace_root_deploy_include_targeting_member_file` — explicit-file case; asserts `main.ts` is included and unlisted siblings (`extra.txt`) are not.
• `deno task build` regenerates `lib/rs_lib.{js,wasm,d.ts}`.
• `deno fmt` / `deno lint` / `deno check` clean.
• `deno test -A tests/create.test.ts` — 17/17 pass.

Repro confirmation

The new tests fail before the patch (`expected .../main.ts in deploy files; got []`) and pass after.

🤖 Generated with Claude Code

[crowlbot]

Superseding the rs_lib workaround with an upstream fix.

The root cause is in deno_config (WorkspaceDirectory::to_deploy_config), which runs the member-include strip shared with fmt/lint/test/bench/publish. For deploy that strip is wrong — a root deploy.include pointing at a workspace member is an explicit instruction to ship those files. This PR worked around it by re-adding the stripped includes after the fact, which is fragile (it duplicates upstream logic and depends on the strip's internals).

I've opened the proper fix upstream: denoland/deno#34788 — it stops to_deploy_config from stripping member includes (the strip stays for the other five config kinds) and adds regression tests for both glob and explicit-file includes targeting a member.

Plan for this PR: once #34788 lands and a new deno_config is published, I'll rework this to drop restore_stripped_member_includes entirely and bump the deno_config dependency to the fixed release, keeping the rs_lib regression tests (they'll then pass against the real fix rather than the workaround). Marking as draft until then so the stopgap isn't merged.